Here is a (old) global overview of the structure of trackers. The aim is to give to the developer a bird’s-eye view of objects relationship and underlying database structure.
Creating a new field
Here are important points to be checked while developing a new field. This applies also for new types of bind for list fields. Please note that some points may be irrelevant for some type of fields.
Setup acceptance criteria in test suite
Tracker Field Structure
Field can be switch to another type (only sb/msb)
Field is duplicated on tracker inheritance (both tracker and project creation)
Definition is NOT given through SOAP @deprecated
Definition is given through REST (representations)
Migrate field from TV3 (if not done)
Does new field can be used for burndown?
Can the field be required?
What level of permissions this field supports?
What does ‘None’ mean for this field?
Field is involved in notifications
New value is sent in notifications
Diff of the field appears in changesets
Get/create/update NOT through SOAP @deprecated
New value is Copyed on Artifact copy
New value can be used in semantic
New value can be updated on masschanges
On an artifact with artifact links, on creating directly a child the field can be used
Field is searchable through criteria
Field is displayed as a column in table
Field is used to sort
Field is used for aggregates
Field is used to build charts
Field is used to build cardwall
Create/ edit modal
Cardwall edit in place
Card field in planning v2
Card field in kanban + filter + highlight
Does field can be directly updated in Cardwall
Modal edit Release
Modal add a Task
User documentation is accurate