Related links
CMS - Content Management & Web API services
FI - Finance Management
Framework Core functionality
- prices
- managementfaq
- prices_private-installation
- clientdefinedattributes
- phplibraries
- servermethods
- io_export
- AyMINE Framework Server
- The AyMINE licence model
- System Rights
- servermethods_frmfrm
- io_import
- multiclient-architecture
- servermethods_stringsandtranslations
- frmevent
- System messaging
- usersessions
Libraries & Lincences
Module - support for management
Front-End Scripting
HR - Human Resources
Mobile & Web Application
- clientprogramming_fevaldataobject
- userinterface-objectstructure
- cliplink
- npmlibraries
- fclip
- drag-drop
- AyMINE Application
- objectdefinition_inlineedit
- npmlibraries_stringlibrary
- clientprogramming
- mobileapplication
- languagesupport
- objectdefinition_multiupdate
- clientprogramming_fevalglobal
- clientprogramming_fevallanguage
- clientprogramming_fevaluser
- objectdefinition_viewdefinition
- offlineobjects
- System console
- Runtime debugging
- objectdefinition_detailview
Sales & Asset management
Sales related services
Description of a part of the AM module - sales partSystem Management (part of framework)
Task, Project, Quality
Task & Task pattern
Client-defined counters
- Type of counters
- Client-defined counter implementation
- Flat counters with short values – flatShort
- Flat counters with long values
- Tree counters
Type of counters
- System counters are defined internally by system and managed by developers.
- Client counters are pre-defined by developers. but its usage and values are defined by system clients. They are not user-counter because their values are defined by client administrator so that users cannot freely change the list of options.
Client-defined counter implementation
Clients can manages values of the counters that are linked with object attributes. All client counters are pre-defined by module configuration file (the m_Conf.jsonc file):
Client-defined counters section:
"clientEnums": {
"flatShort":{
},
"treeLong":{
"caseGroup":[]
}
},
There are several types of the counters. Neither of them currently supports translation of the strings so that all client employees works with the same set of strings in the language how they are defined. As mentioned later user-defined counters are stored as a full value in the system, so that translation is not possible.
Flat counters with short values – flatShort
Values could be up to the 20 characters long. Values are stored directly to the field, that reference them. When client changes the counter definition, the filled values are not affected.
User cannot change value from the counter inserted to the field although it technically could be possible (values is stored everywhere where it was placed.)
Usage example: Type of the emplyee absence
Counters with short values could also be used as multiple-values counters. Fields for multiple value coutners should be long enough to include all short values. Typically the field is 100 – 120 characters long and user can select up to 5 values with the 20 characters.
Fields in the multiple-value counters are always filled with all values selected from counter.
Usage example: Tags of the project requirements
Flat counters with long values
Counters with long values (up to the 80 charactes) are used for short default strings insereted to the description items.
Usage example: Reasons, why some task is rejected
User can user the pre-defined string from long-text counter, modify it or even write it's own text.
Tree counters
Tree counters are used in different way. They creates hierarchical list of values and user select value from a tree. Value is not stored in the field where it was selected but the field stores link to the value in the tree. When administrator rename the field in the counter a new value is visible in the field. If admininstrator deletes the filed, values becomes invalid.
Each counter field could have name long up to the 80 charactes and can have as many child as necessary.