The goal of this project is to create a module (or modules) that will enable end-users to better customize an instance of Agasti through the frontend.

The front-ends should be part of the admin module, unless they grow in number to the point at which they should receive a module of their own. They should also be made accessible through the Admin portion of the Agasti main menu. If the edge table being worked on is part of Agsasti core, templates and actions for the module should be stored appropriate directory beneath /apps/frontend/modules/admin, and other files in (form, models, utilities, helpers) should be stored in in the proper directory beneath /apps/frontend/lib. If the module being worked on is not core, but rather one of the packages, actions and templates should be stored in the appropriate directory under /apps/frontend/packages/[agPackage]/modules/. Models, forms, and helpers for edge-tables available only through a package should be stored under /apps/frontend/packages/[agPackage]/lib/.

The visual style of edge-table front-ends should conform to Agasti's overall appearance. Front-end URLs should also be well formed and informative to the user.

The Agasti schema has been designed to be incredibly flexible and configurable by the end user, allowing for customization to meet very specific needs. To take full advantage of this design, a front-end is needed to define various definition/edge/configuration tables. The Admin module would be the best place to keep these (and the admin menu would be the best place to link to them), unless they grow so numerous that they need their own module. In short, pages that allow administrative users to change or add data-points like name-types, email-types, phone-type, address-type. Currently, this can only be done by editing YML files of modifying the database directly.

The functionality that will be made available by the completion of this task will allow users to more fully configure an instance of Agasti. It will also allow the application to take full advantage of the underlying database schema, some of which is presently locked down or is inaccessible save through the database or editing the code.

Agasti will package at least one standard setup, but by making its basic setup configurable through the front-end, users will be able to take a bare-bones Agasti instance and tailor it to a specific event, locale, or other need.

Possible End Products

1. Configuring necessary data-points for clients and staff Both the agClient and agStaff business objects extend agPerson, and thus, have all of the associated data-points available through the front-end. There could certainly be cases where an end-user does not need all of the agPerson data-points for staff, client, or both. For example, a user in an area that sees a large deal of international traffic may want to collect nationality information (definitions stored in the agNationality table, joined to the agPerson table by agPersonMjAgNationality) on clients, but not on staff. The setting of an agGlobalParam or two , either during installation or through the Admin module afterwards, could be used here to enable or disable the visibility of agNationality data on the view and edit pages for staff or clients. The agGlobalParam entries for this use case might look something like this (the relevant values are in the 'datapoint' and 'value' columns):

1. Defining ag[Data-point]Type Values As the creation and application of names, email addresses, phone numbers, and a few other objects in Agasti requires the creation of and joining of values (the actual name or email address), type (is it a home phone number or a work phone number?), and entity (a person, place, or thing) through one of the join tables, a feature that allows users to configure the 'type' values could prove useful to the end user. This configuration might best be set during installation (or after if no fixtures have been loaded to the tables during installation), as to avoid superfluous or inaccessible type values that may result from modification post installation, but robust error reporting and correction suggestion or some kind of type-migration-wizard (allowing users to map an old name type to a new name type, or perhaps even just changing the value of one name type entry) could also make this usable after installation and data load. Some users may only want to include first (or given) and last (or family) name data, others may want the full Given-Middle-Family-Maiden-Alias set that currently ships with Agasti, still others may want only first and last, but with an unlimited number of alias names. All of these are possible with the Agasti schema, and could be configured through the front-end.
2. Setting of default_address_standard and default_phone_format_type Currently, agGlobalParam has datapoint:value pairs of default_address_standard:us standard and default_phone_format_type:USA 10 digit. The creation of different address definitions (which would require additions to the agAddressStandard, agAddressFormat, and (possibly) the agAddressElement tables) and the setting of the default address standard would both be worth implementing. As would the creation of phone number definitions (using the agPhoneFormat and agPhoneFormatType tables) and setting of the default_phone_format_type (agGlobalParam).
3. Implementation of app_display Several tables contain an app_display column, which can be used in front-end coding to determine which options from these tables will be available for selection in the front-end forms. A module for this would be extremely useful, and could be a good starting point for contributors. A list of all values in a table with the app_display column matched with a checkbox to enable or disable app_display would be a good front-end design for this. Currently, there is a module in development to implement app_disply on the agProfession table. It can be accessed through /admin/display.

This project should not modify parts of Agasti core or any Agasti package except where absolutely necessary. See the 'Open Issues' section for some notes on where this will be necessary. The data-points that will be made accessible through these front-ends should, for the most part, be small and defined by a single table, so there will be no need to work with business objects as large as those that define things like an entire person, staff-person, or address.

Currently, some of Agasti's functionality is hard-coded to rely on specific schema values, such as name-type, US states in address definitions, and a few other points. By making customization of edge tables available to end users, there is a risk of breaking these parts of the program. These issues should be taken into account when working on these new configuration modules, and existing code refactored to be compatible with changes and end-user may make while setting up Agasti. Judicious use of the agGlobal table might be of great use here. Known and noted cases should be listed below.

These modules should be accessible through the Admin section of the main Agasti menu. As such, they will be available from any page in the installation, provided the active user has the appropriate permissions to access them.

This should be fleshed out more fully, but some of these settings may be best used as part of the installation process.

Most work-flows should consist of a single page with the appropriate form or forms. Use of the jQuery modal window may also be useful to modify or add minor data-points.

Note on contribution: Please feel free to fill out sections of the specification as this project is a collaborative effort; however, if you feel your ideas could be in conflict to previous ideas or you want to change sections already fleshed out please use the discuss tab first and find consensus with others working on this module or section.