Ethical Issues in the Use of Facial Recognition Technology in Public Spaces

Facial recognition technology (FRT) is increasingly used in public spaces for security and commercial purposes. However, its deployment raises ethical concerns, particularly around consent, transparency, and potential misuse. This article explores these issues, focusing on privacy concerns, informed consent, and transparency.

Privacy Concerns

The use of FRT in public spaces poses significant privacy risks. Individuals often have no choice or awareness that their facial data is being collected and analysed, leading to a loss of anonymity and a chilling effect on personal freedoms. FRT can monitor and record people’s movements without explicit consent, raising substantial privacy issues (Whittaker et al., 2018).

Enhanced security measures in Australian supermarkets like Coles and Woolworths have intensified these concerns, with customers potentially feeling constantly watched and at risk of data misuse (Mitchell, 2023). Increased surveillance may disproportionately affect vulnerable individuals, raising fairness concerns (Wahlquist, 2023).

Data security is another major concern. The 2020 Clearview AI data breach exemplifies the risks of managing sensitive information, exposing a vast database of facial images and customer lists (Cimpanu, 2020; Eddy, 2020). The OAIC found that Clearview AI’s practices violated Australian privacy laws by scraping biometric information without consent (OAIC, 2021).

Data is Never Really Raw or Neutral

Data, including facial recognition data, is never truly raw or neutral. It is influenced by the biases and intentions of those who collect and analyse it (Crawford & Paglen, 2021). This underscores the need for transparency in data collection and measures to mitigate bias and ensure fairness.

Consent and Transparency

A fundamental ethical issue with FRT in public spaces is the lack of informed consent. Individuals often are unaware their facial data is being captured and used (Graham, 2020). Surveillance in supermarkets raises further concerns about the voluntariness of consent (Mitchell, 2023). This lack of transparency can erode trust between customers and businesses (Handle My Complaint, 2024).

The OAIC recommends transparency about FRT practices, including clear information about how facial data will be used, stored, and protected (OAIC, 2021). Despite these recommendations, there is no dedicated legislation governing FRT use in Australia. Existing privacy laws, like the Privacy Act 1988, apply but can be exploited (Handle My Complaint, 2024).

Legal and Ethical Frameworks

Legal frameworks governing FRT use in public spaces are often inconsistent and lag behind technological advancements. The GDPR in the European Union sets a high standard for data protection and consent, but such robust regulations are not universally applied. In many jurisdictions, gaps in legal protections leave individuals vulnerable to privacy violations (European Parliament, 2016). Australia’s privacy laws, for example, are considered to be falling behind the rapid advancement and deployment of FRT technologies (Forbes Australia, 2023).

Ethically, FRT deployment involves balancing security benefits and individual rights. Utilitarian perspectives might justify FRT use for public safety, but these benefits must be weighed against potential harms to privacy and personal freedom. Virtue ethics emphasise respecting individuals’ autonomy and dignity, advocating for transparency and consent (Internet Encyclopedia of Philosophy, 2021).

Theoretical Perspectives on FRT Ethics

Data collection and processing are influenced by the biases and intentions of those who create and deploy these technologies (Crawford & Paglen, 2021). Utilitarianism, which focuses on the greatest good for the greatest number, can justify FRT use for public safety. However, this approach may overlook significant privacy infringements and potential harms to individuals who are misidentified or unjustly surveilled (Mill, 1863). Deontological ethics, which emphasise duties and rights, would argue against FRT use without explicit consent, prioritising individual autonomy and privacy over collective security (Stanford Encyclopedia of Philosophy, 2021).

Breaking the Deadlock: A Balanced Approach

The ethical debate around FRT often falls into a deadlock between deontological and consequentialist perspectives. A more balanced approach that integrates elements from both theories can provide a more nuanced ethical framework. This approach recognises the potential benefits of FRT for public safety while upholding individual rights and ensuring fairness and non-discrimination (Internet Encyclopedia of Philosophy, 2021). This aligns with OpenAI’s emphasis on “ensuring that AI systems are used safely and fairly” (OpenAI, 2022).

Corporate Moral Agency and Accountability

Another important consideration is the moral agency of corporations developing and deploying FRT. While corporations are not individuals, they wield significant power and influence, shaping societal norms and values through their technologies. Recognising corporate moral agency means holding these entities accountable for ethical lapses and ensuring they adhere to ethical standards (Goodpaster & Matthews, 1982).

A Code of Ethics for FRT in Public Spaces

A code of ethics for the deployment of FRT in public spaces should include the following principles:

• Transparency: Clearly disclose where and how FRT is being used, including the purpose, data retention policies, and potential consequences.
• Consent: Obtain meaningful and informed consent from individuals before collecting or using their facial data. Consider alternative identification methods for those who do not consent.
• Accountability: Establish clear lines of responsibility for data breaches and misuse. Implement mechanisms for redress and independent oversight.
• Equity: Ensure that FRT does not disproportionately affect marginalised communities. Conduct regular audits to identify and mitigate biases in algorithms, as emphasised by organisations like the Algorithmic Justice League (2020).
• Privacy Protection: Implement robust data security measures to protect individuals’ information. Minimise data collection and retention, and anonymise data where possible.

Future Directions and Community Engagement

To address the ethical challenges of FRT in public spaces, it is crucial to develop robust legal and ethical frameworks that prioritise transparency and informed consent. Governments and organisations should implement clear policies outlining the purposes and limits of FRT usage, ensuring that individuals are informed and can exercise their rights (Mittelstadt et al., 2016).

Community engagement is vital in this process. Public discussions and stakeholder involvement can help shape the ethical deployment of FRT, ensuring that diverse perspectives are considered. Initiatives like public forums and consultations can foster greater transparency and trust, enabling a more democratic approach to technology governance (Whittaker et al., 2018).

Conclusion

The use of facial recognition technology in public spaces raises significant ethical concerns, particularly regarding privacy, consent, and potential misuse. Addressing these issues requires robust legal frameworks, ethical guidelines, and active community engagement. By prioritising informed consent, transparency, and fairness, we can ensure that the deployment of FRT respects individual rights and fosters public trust, aligning with the principles advocated by organisations like OpenAI and the Algorithmic Justice League.

References

Algorithmic Justice League. (2020, May). Fighting bias in facial recognition technology. https://assets-global.website-files.com/5e027ca188c99e3515b404b7/5ed1145952bc185203f3d009_FRTsFederalOfficeMay2020.pdf

Cimpanu, C. (2020, February 27). Clearview AI customers exposed in data breach. Dark Reading. https://www.darkreading.com/cyberattacks-data-breaches/clearview-ai-customers-exposed-in-data-breach

Conger, K. (2019, May 14). San Francisco bans facial recognition technology. The New York Times. https://www.nytimes.com/2019/05/14/us/facial-recognition-ban-san-francisco.html

Crawford, K., & Paglen, T. (2021). Atlas of AI: Power, Politics, and the Planetary Costs of Artificial Intelligence. Yale University Press. https://ebookcentral.proquest.com/lib/uts/reader.action?docID=6478659

Eddy, N. (2020, March 2). Breach of Clearview AI server exposed source code, secret keys and more. Channel Futures. https://www.channelfutures.com/artificial-intelligence/breach-of-clearview-ai-server-exposed-source-code-secret-keys-and-more

European Parliament. (2016). General Data Protection Regulation. https://gdpr-info.eu/

Forbes Australia. (2023). Facial recognition is everywhere but Australia’s privacy laws are falling way behind. https://www.forbes.com.au/news/innovation/facial-recognition-is-everywhere-but-australias-privacy-laws-are-falling-way-behind/

Goodpaster, K. E., & Matthews, J. B. (1982, January-February). Can a corporation have a conscience? Harvard Business Review. https://hbr.org/1982/01/can-a-corporation-have-a-conscience

Graham, E. (2020, June 15). Australia’s use of facial recognition technology raises privacy concerns. ABC News. https://www.abc.net.au/news/2020-06-15/facial-recognition-technology-privacy-concerns/12347728

Handle My Complaint. (2024, February 27). Privacy risks: Tackling facial recognition technology head-on. https://handlemycomplaint.com.au/2024/02/27/privacy-risks-tackling-facial-recognition-technology-head-on/

Internet Encyclopedia of Philosophy. (2021). Virtue Ethics. https://iep.utm.edu/virtue/

Mill, J. S. (1863). Utilitarianism. [Original work published 1863]. https://www.utilitarianism.com/utilitarianism

Mittelstadt, B. D., Allo, P., Taddeo, M., Wachter, S., & Floridi, L. (2016). The ethics of algorithms: Mapping the debate. Big Data & Society, 3(2), 1-21. https://doi.org/10.1177/2053951716679679

Mitchell, S. (2023, May 17). Experts warn about customer privacy after ‘drastic’ security moves by supermarkets. news.com.au. https://www.news.com.au/finance/business/retail/experts-warn-about-customer-privacy-after-drastic-security-moves-by-supermarkets/news-story/66e0ee85491eacf49fe18e30ee49197e

Office of the Australian Information Commissioner (OAIC). (2021, November 3). Clearview AI breached Australians’ privacy. https://www.oaic.gov.au/newsroom/clearview-ai-breached-australians-privacy

OpenAI. (2018). OpenAI Charter. https://openai.com/charter

OpenAI. (2022, January 5). Our approach to alignment research. https://openai.com/blog/our-approach-to-alignment-research

Stanford Encyclopedia of Philosophy. (2021). Deontological Ethics. https://plato.stanford.edu/entries/ethics-deontological/

Wahlquist, C. (2023, November 29). The self-serve is frustrating, but it’s not the biggest supermarket privacy concern. The Sydney Morning Herald. https://www.smh.com.au/technology/the-self-serve-is-frustrating-but-it-s-not-the-biggest-supermarket-privacy-concern-20231129-p5ensd.html

Whittaker, M., Crawford, K., Dobbe, R., Fried, G., Kaziunas, L., Mathur, V., … & West, S. M. (2018). AI Now Report 2018. AI Now Institute. https://ainowinstitute.org/AI_Now_2018_Report.pdf

Accounting

This entry was taken from web archive – in an effort to preserver it from being lost forever –
Author: Michael Wigley

Double Entry Accounting in a Relational Database

INTRODUCTION

Many computer systems utilising a relational database contain some sort of accounting information. In the initial design and development stages there is often a debate about what type of accounting strategy should be used by the software to record this information. The decision is usually between a simple and cheap ‘single entry’ accounting system and a more complex ‘double entry’ accounting system.

A ‘single entry’ system is one where the numerical values being stored are only recorded once. In a ‘double entry’ system each value is stored twice, once as a credit (a positive value), once as a debit (a negative value). There are a number of rules that control these values. These rules would be recognised by any trained accountant although they may not understand how it is stored in a relational database. The main rules are as follows:

1. Every entry into the system must balance – i.e. the sum of any transaction must be zero.
2. The sum of all the values in the system at any one time must be zero (the ‘trial balance’).
3. No values can ever be amended or deleted. They must be negated with an opposing entry (a ‘contra’) and re-entered (‘re-booked’). This provides a completely secure audit trail.

APPLICABILITY OF DOUBLE ENTRY ACCOUNTING

At the outset of a project the cost of a simple accounting system is always appealing. The complexity and effort of a full blown ‘double entry’ system often seems difficult to justify. In reality going for a simple ‘single entry’ system is usually a false economy. If the accounting information is just mirroring a paper system outside the database then a single entry system might be acceptable, however, if any of the following apply then a full ‘double entry’ mechanism ought to be implemented from the outset:

1. If the information will ever need to be audited by an accountant
2. If the information held is the sole record of ownership
3. If the information held represents high value assets.
4. If the system is likely to expand and grow in the future.

A DOUBLE ENTRY EXAMPLE

The key factor of a double entry system is the presence of a ‘cash book’ account. This account contains the entries made when assets (e.g. money) are taken into or released from the accounting system. As such the total value of this account always matches the total value of the assets in the system.

Using accountant’s ‘T charts’ to represent this we use the following example that uses two accounts only. The ‘cash book’ and an account in the name of ‘Smith’.

(a) £300 is entered into this system to be allocated to the Smith account. The £300 is credited to the Smith account (credits are on the right, debits on the left). To match this a debit of £300 is allocated to the Cash Book.

(b) If £50 is taken out of the system from the Smith account, £50 is debited from the Smith account and credited to the Cash Book.

(c) If another account is added in the name of Pattel and £100 is transferred from Smith to Pattel then £100 is debited from Smith and £100 credited to Pattel.

(d) To complete the picture £60 is taken out of the system from the Pattel account with a debt from Pattel and a credit to the Cash book.

At the end of this the Smith account balance is £150, the Pattel account is £40 and the Cash Book is £-190, the negative sum of the other accounts. On this simple basis very complex asset tracking systems can be built.

THE ACCOUNTING DATA MODEL

A simple data model that can be used to represent this information is illustrated below:

The POSTING table contains the actual accounting double entries. Keeping the figures in one table simplifies the mathematics dramatically. The primary key or part of the primary key of the POSTING table should be a system generated sequence number. It should also be generated in such a way that no gaps can appear in the sequence (through a transaction rolling back, for example). This is part of ensuring that no entries are ever deleted. The BATCH and JOURNAL tables are used to control the input of the double entries to this POSTING table.

A JOURNAL entry is the data representation of any business transaction that will produce double entries – it represents a complete unit of work. I.e. all POSTING entries associated with the JOURNAL entry must be successfully completed or none must be completed. The numerical sum of all POSTING entries associated with a JOURNAL entry must also equal zero (the only way the total value contained in the system can be amended is though the Cash Book). Each transaction described in the example above would be represented by one JOURNAL entry.

A BATCH entry reflects the more physical aspects of accounting data entry. It is used to group together JOURNAL entries into handy ‘chunks’, for example, a collection of cheques to be entered into the system, a collection of information from an Electronic Data Interface (EDI) or a global business process like the payment of interest to all accounts.

The ACCOUNT table represents the owner of the assets in the system. In most systems the ‘pigs ear’, recursive, relationship to itself will not be needed. This is only required if a system of ‘nominee’ type accounts is required where concepts of group ownership are mixed in with individual ownership.

The ASSET TYPE table contains the list of asset types being held in the system. By making the asset type part of the POSTING primary key the system becomes a multi-asset (e.g multi-currency) system. Through use of this, the system can also track the ownership of other ‘de-materialised’ assets where the actual ownership of any particular item isn’t required just the type and quantity owned. Examples of this type of asset includes shares and agricultural or pollution quota. It can also track ‘bearer’ assets (where, for example, the fact that certificate number 12345 belongs to Mrs X is important).

The above example is shown below as entries in this data model (the column list is kept as simple as possible for clarity).

ACCOUNT

Id	Name
SMITH	Mr J Smith
PATTEL	Mr R Pattel
CASH	The Cash Book

JOURNAL

Id (as used above)	Type
a	Deposit
b	Withdrawal
c	Transfer
d	Withdrawal

POSTING

Id	Account Id	Journal Id	Asset Type	Amount
1	SMITH	a	£	300
2	CASH	a	£	-300
3	SMITH	b	£	-50
4	CASH	b	£	50
5	SMITH	c	£	-100
6	PATTEL	c	£	100
7	PATTEL	d	£	-60
8	CASH	d	£	60

The balance of the POSTING Amount column always being zero after every complete JOURNAL transaction (and the software must not allow an incomplete one). From the above the total in the Cash Book adds up to –190 which is the negative sum of the 150 belonging to Smith and the 40 belonging to Pattel.

To expand this system into a multi-currency system a new asset type is added and used. If Mr Smith wished to change £20 into dollars at a rate of £1 to $1.5 the transaction is made though the Cash Book as follows (the required POSTING entries):

Id	Account Id	Journal Id	Asset Type	Amount
9	SMITH	e	£	-20
10	CASH	e	£	20
11	CASH	e	$	-30
12	SMITH	e	$	30

ACCOUNTING PERIODS

Our accounting model so far is perfectly sound but could creak under high volumes as we can never delete anything. Most accounting requirements include the concept of an accounting period, maybe monthly, three monthly or yearly, for example. Whilst there is no need to constrain the logical requirement for an accounting period by tying it too closely to the physical model it provides a useful indication as to where to break flow of the data. The year end is often a convenient point, either the calendar year end or the financial year end. By adding a period indicator column to the POSTING table (and also to its primary key) the data can be split into discreet time chunks that can be validated independently. If in the above example the next set of entries fell into the next accounting period the balances outstanding are brought forward as summary entries in the next period first (leaving out the currency exchange example for simplicity).

Firstly the balances for the previous period are cleared down.

Id	Account Id	Journal Id	Account Period	Asset Type	Amount
9	SMITH	e	YEAR 1	£	-150
10	CASH	e	YEAR 1	£	150
11	CASH	e	YEAR 1	£	40
12	PATTEL	e	YEAR 1	£	-40

Then the balances are carried forward to the next period.

Id	Account Id	Journal Id	Account Period	Asset Type	Amount
13	SMITH	e	YEAR 2	£	150
14	CASH	e	YEAR 2	£	-150
15	CASH	e	YEAR 2	£	– 40
16	PATTEL	e	YEAR 2	£	40

After an appropriate period of time the previous YEAR 1 period can be archived and deleted from the system.

AGGREGATING TRANSACTIONS

There are some activities that occur within accounting systems that are large scale changes that affect many or all of the accounts. For example, payment of interest to all accounts as a percentage of their current balance or a global cut of quota by a certain percentage. The end of year example above also falls into this category. The end of year entries should all be done under the same JOURNAL (although it could be argued that separate currencies/assets could be done under separate journals) but it is quite acceptable to aggregate the entries to the Cash Book. The accounting rule requirements will still be met but it will simplify the work and volumes involved by up to 50%. The POSTING entries in the above end of year example then become:

Id	Account Id	Journal Id	Account Period	Asset Type	Amount
9	SMITH	e	YEAR 1	£	-150
10	CASH	e	YEAR 1	£	190
11	PATTEL	e	YEAR 1	£	-40
12	SMITH	e	YEAR 2	£	150
13	CASH	e	YEAR 2	£	-190
14	PATTEL	e	YEAR 2	£	40

BATCH ENTRY

A batching mechanism is often used to facilitate data entry to this accounting system. In its historic form this is what has happened for the processing of cheques. An account clerk would be given a pile of ten cheques, a batch number and the total value of the cheques. An entry screen would then be used by the clerk to record the cheques as ‘unauthorised’ entries. At the BATCH level the number of cheques and their total value is recorded and only when the number of items entered and their totals match these figures is the user allowed to commit the batch. Once this activity is complete the batch is passed to another member of staff who checks the contents of the batch (either on-screen or with the aide of a report) and then ‘authorises’ the batch if it is correct. This process is generally referred to as ‘maker/checker’ and can be adapted for the manual entry of any primary asset data. The concept of a Batch is also useful for electronic data transfer as it provides a method of aggregation for audit trail and correction processing. As a rule it is sensible to keep the details of ‘unauthorised’ entries in separate tables from those ‘pucker’ double entries made by the ‘authorisation’ process into the POSTING table. If this is done it is also possible to simplify the programming effort by creating tables more appropriate to the business function in hand. For example, in the above cheque entry process the clerk will only have to identify one account. The other account, the Cash Book, is implicit as the movement of money will always be from the Cash Book to the owners account. A CHEQUE table would only require one Account column where as a hypothetical FUND TRANSFER table would need two, a ‘From Account’ column and a ‘To Account’ column.

This is where most of the confusion over the concepts of double-entry principles arise. Most people only come across simple paper Cash Books in the normal course of domestic events. In a paper Cash Book used for example, to record a club’s funds, only one entry per transaction is required. This is still an implicit double entry system because, as only one account is represented (the ‘club’ in this example) the opposite entry can only ever go against the Cash Book – it is only ever a movement into the system (into club funds) or out of the system (paid out of the club funds). This is also where the other main source of confusion occurs. An individual’s bank statement will show money paid into the bank account as a ‘credit’ because the individual is a creditor to the bank – they have that individual’s money. If that same individual ran a Cash Book this figure should be represented as a ‘debt’ – the bank owes the money/is in debt to that individual. The money is out of that individuals system and in the bank’s.

CODE DESIGN

The modules required to support a double entry accounting system are best designed using a tiered, Object Oriented (OO), approach. The tiers used are as follows

1. Interface processing (user and electronic)
2. Business processing
3. Database processing

A full design is dependent of the type of system required but the following hypothetical modules could exist in each layer.

PostEntry: A module to make a basic POSTING entry is required at the database layer. This will insert a record adding timestamps and sequenced identifiers automatically. It cannot delete or update records and no other module will be allowed to update, insert or delete records apart from an archiving module to do deletions. The POSTING table is read-only for all other purposes.

MakeDeposit, MakeWithdrawal, MakeTransfer: Modules to perform basic business process will exist at the Business layer. They will call PostEntry in the appropriate manner.

ChequeEntry and ChequeAuthorisation screens, ReceiveBACS interface module: Modules to link the system to the outside world will reside in the Interface layer. These modules will call the appropriate Business layer objects to perform the business functions. In this way the same processing can be guarantied regardless of the method of entry because, for example, ChequeEntry and ReceiveBACS would both call the same MakeDeposit module.

This methodology can be used to a lesser or greater degree depending on the complexity of the system and the adherence to ‘purist’ OO principles. It may be sensible, for example, to allow reports (e.g. TestTrialBalance) to be written to access the tables directly from the Interface layer – rather than building intermediate layer modules to do the work.

THE TRIAL BALANCE

The ‘trial balance’ is the main method of ‘proving’ the integrity of any accounting system. If all the entries made into the system have been made in accordance to the double entry rules and are not corrupt in any way then the sum of all these entries will always equal zero. The chance of an equal and opposite, matching, error occurring is so small that it can be completely discounted. The best way to run a trial balance is to start at the highest level and only break the figures down if a problem occurs. Using the above table structure the parameters for these queries are as follows:

1^st Sum the values in the POSTING.Amount column.

Then if that fails

2^nd Sum the values in the POSTING.Amount column but broken down by Asset Type and Account Period.

This should indicate where the problem lies. The fact that the sum of every JOURNAL should also equal zero can then be used to track down the POSTING entries that are in error.

JOURNAL ENTITY SUPER-TYPES

The JOURNAL table is the simple representation of an entity or entities that are often more complex and involve super and sub type relationships. The JOURNAL entity could be broken into MATERIALISED and DEMATERIALISED (these might have different attributes because things like certificate numbers or physical location would be required for the MATERIALISED type assets). Alternatively the asset types could define the JOURNAL sub-types resolving them into CURRENCY TRANSFERS, STOCK TRANSFERS, COMMODITY TRANSFERS each having different attributes. Entities with super and sub types can be resolved into tables in one of four ways (these are standard data modelling principles):

1. Have one big table with many optional columns to represent the sub-type attributes.
2. Have a separate table for each sub-type duplicating the columns that are common (those columns that are inherited from the super-type’s attributes).
3. Split the entities so that the super-type has one table with its columns and this must be joined to other tables that represent each sub type which contain the sub-type columns only. An ‘arc’ is placed on the one-to-one relationships between the sub-types and the super type.
4. Split the entities as in (3) above but duplicate the super-type table columns on the sub-type tables.

There are pros and cons for the use of each of these methods. From a double entry accounting perspective it is useful to have the super-type table to provide a natural focus for the POSTING entries – this would rule out option (2). Otherwise option (1) is probably best for a simple accounting system (which is effectively what the example used through out this article is – the JOURNAL Type column acting as the sub-type discriminator column) but option (3) would probably be best for a complex system with asset types with wildly differing properties.

Author: Michael Wigley

(Michaelwigley@bcs.org.uk)

Drupal 7 – Add module paths to theme registry (theme suggestions for modules)

Drupal allows for “theme suggestions” which allows one to add extra theme templates to your theme and Drupal will automatically find them and use them, but this does not work if you want to have your templates in a module directory. (http://drupal.org/node/1089656)

Now the problem/process is that Drupal only does an automatic find of theme templates and functions using the functions “drupal_find_theme_templates & drupal_find_theme_functions” when it invokes the _theme_process_registry on a templating engine, this can be seen in the “hook_theme” implementation of phptemplate (phptemplate.engine), this means that the find is done at the lowest “theme” level only, (probably for better performance reasons, I have not looked into it).

What I learnt from this is.

• If the variable “theme_hook_suggestion” exists then it will take preference over ALL others (check around line 1118 theme.inc)
• The basic workflow for a theme is to first run _theme_build_registry, which calls _theme_process_registry on each module hook_theme implementation.
  it also calls hook_theme on each engine and them implementation.
• _theme_build_registry then allows you to hook into it and alter the cache built by invoking theme_registry in your module.

So what we need to do to get drupal to do an automatic lookup of our files is simply invoke those two functions on our modules theme path and then add them to the registry.

function uql_shortcode_theme_registry_alter(&$theme_registry) {
$templates = drupal_find_theme_functions($theme_registry);

/* PATH is important its the path to your module dir with the templates: */
$templates += drupal_find_theme_templates($theme_registry, '.tpl.php', PATH);

// Grab only the "extra" ones we have found and add them to the registry
$theme_registry += array_diff_key($templates,$theme_registry);
}

When eclipse says: An error has occurred. See the log file .metadata/.log.

Eclipse error: An error has occurred. See the log file .metadata/.log.
This has happened to me a few times, I am not sure what actually causes it but this fix works for me.
Navigate to this folder:
/YOUR PATH TO WORKSPACE/.metadata/.plugins/org.eclipse.core.resources
inside you should see a file called “snap“, delete this file, restart eclipse. this works for me every time and all my settings are kept.

Pass Kendoui datagrid variable to template that uses Zend Url

Passing a variable from a Kendo Ui datagrid to a custom template on things like edit/delete can be a little tricky, and it gets even harder when Zend encodes the url too.

Basically I had a Kendo Ui Data Grid.

I wanted to create my own edit/delete links for each field rather than make the grid editable.
The trick was to to create a template for the field I wanted to add the links in, then to pass the id of the field to the template.

dataSource: {
  transport: {
   read: "http://demos.kendoui.com/service/Northwind.svc/Orders"
 },
  schema: {
     model: {
        fields: {
          field1:{},
          field2:{},
          field3:{}
        }
    }
},

EDIT: All fields you define in the data-source model will also be available to the template

Here is how I did it

The data grid looked like this:

 $(document).ready(function() {
                $("#grid2").kendoGrid({
                    dataSource: {
                        type: "odata",
                        serverPaging: true,
                        serverSorting: true,
                        pageSize: 100,
                        transport: {
                            read: "http://demos.kendoui.com/service/Northwind.svc/Orders"
                        }
                    },
                    height: 280,
                    scrollable: {
                        virtual: true
                    },
                    sortable: true,
                    columns: ["OrderID", 
"CustomerID", 
"ShipName", 
"ShipCity",
{ title: "Manage", 
  field: "OrderID", 
  template: kendo.template($("#template").html())
} ]
                });
            });

The bit that stumped me initially until I realised how obvious it was. Pass the field you want to the template by specifying the “field” (in this case its OrderID) , for some reason I thought it would magically inherit the fields already defined previously, that is not the case.

And here is the template itself: this is all in the view page of the Zend app.
the trick here was to ensure you decode the URL else the id does not get picked up by the javascript

      <script type="text/x-kendo-template" id="template">
       	<a href="<?php echo urldecode($this->url(array('controller'=>'product-type', 'action'=>'edit','id'=>'#= OrderID#')));?>">Edit</a> | 
	<a href="<?php echo urldecode($this->url(array('controller'=>'product-type', 'action'=>'delete','id'=>'#= OrderID#')));?>">Delete</a>

      </script>

Zend greaterThan validation and message changes

Adding the greaterThan Validator to an elements, setting its min value AND changing its return message was a little tricky.

The main problem is finding the actual valid/invalid declaration, for each type of validator its different, so you need to look at the actual class and find it in there:

Here is how I did it in Zend Framework

$projectModel = new App_Model_DbTable_Project();
   $projects = $projectModel->getProjectList();
   array_unshift($projects,'-----Select Project ----');

   $project = new Zend_Form_Element_Select('projects');
   $project->setLabel('Project')
   ->addMultiOptions($projects)
   ->addValidator('greaterThan',true,array('messages'=>array('notGreaterThan' =>'Please select a project'),'min'=>0));

Zend Yes/No Checkbox Decorator

The problem with Yes/No Check boxes is you need a description of the item you are saying yes/no too, you also need the label yes/no

Here is how I did it in Zend Framework

$status = new Zend_Form_Element_Checkbox('proj_status');
$status->setLabel('Yes')
->setDescription('Project Status')
->setDecorators(array(
array('ViewHelper',
array('helper'=> 'formCheckbox')),
array('description',
array('tag' => 'dt', 'placement' =>'PREPEND')), // Change this to be any tag you want
array('label',
array('placement' =>'APPEND')), // Could add a tag here too
)
);

Install Compass & SASS on Windows 7

On your Windows environment, you’ll need to install Ruby via the installer: http://rubyinstaller.org/about/contributors/ after running the setup open the commandline: (Windows run > type: CMD, the latest version of ruby installer 1.9.3 has a command prompt in the installation folder in program files)

Check if ruby is installed, navigate to the Ruby bin folder, and type:
ruby -v

$ gem install haml
$ gem install haml-edge
$ gem install compass

To install SASS  & Compass on Windows 7, is not that hard, however because I was in a corporate environment, I had to set my HOMEDIR Environment variable so that it would work correctly.

When I Tried to install Compass with:

$ gem install compass

I would get the error:  ERROR: While executing gem … (Errno::ENOENT)
I checked the environment variables by running:

$ gem env

But this did not really help.

After some searching I found this link:  Troubleshoot Gem which explains the problem.

Cause:

• If HOME environment variable is not set, Ruby tries to use a combination of HOMEDRIVE and HOMEPATH (e.g. the unaccessible network drive) and fails.

Workaround:

• On the command line, execute “SET HOME=%USERPROFILE%”, which will tell Ruby to use your user profile directory (C:\Users\xyz) as the home directory.