Fields, attachments and notes
The myTracker data are organized in issue records. An issue record have fixed properties and can have custom properties.
One issue-record can have several attachments and notes.
Type of issue fields:
- Choice list - User can choose one of defined value (Combo Box filled with strings)
- Choice user - User can choose one user myTracker user (Combo Box with user names)
- String - String with maximal length 50 characters
- Float - Floating point number with range from 5.0 x 10^-324 to 1.7 x 10^308
- Integer - 32 bit signed integer
- Date - SQL Date type
- Date with time - SQL Timestamp
- Boolean - can have one of (True, False) value (Checkbox)
- Tree - User can choose one of defined value. The values are organized hierarchical in trees.
Beside type have issue fields these properties:
- Name - DB table column name/variable name
- Range from-to validity range for numbers
- Label - Form control caption
- Hint - Form control hint
- Input mask - string field input mask
- Read only - Cannot modify the property value
- Required at - Not required, required at opening, required at closing
- Length - Set the maximal length for string fields (the overall maximum length can you set in project properties)
- Regular expression - Multiline input fields input format can you declare with regular expression instead of input mask (for one line input fields).
Is specialized issue field type used for quick choice of limited number of values.
For example issue type with values : Bug, Change request, New feature, Knowledge. Each value
can have own font style (Normal, Bold, Italic) and font color.
It is possible to define disabled user group for every Choice list element. It means,
this user group can not select (and view) this element. Very useful for distinguishing
user groups (programmer vs. beta tester).
Another feature visible on the picture is the possibility to define disabled elements for each
element of choice list. This feature allowed to define element selection order (tree).
For example: we have a property for bug status with elements : submited, analysing, programming, testing, solved and not a bug.
We can define a changes tree:
And now translate it to program logic program. For submited are disabled programming, testing, solved and not a bug.
For all but bug are disabled submited, analysing, programming, testing and solved.
Every server must have these fixed properties:
||Date with time
||Date with time
Trees are evolution of choice list. The tree unlike choice lists allow you
effective manage dozens values. Very handy for organising program functions into modules and groups.
So you can define a tree structure:
And so it will be live rendered.