Trackers ======== Structure --------- 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. .. figure:: ../images/diagrams/tracker-structure.png :align: center :alt: Overview of tracker structure :name: Overview of tracker 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 * Specific properties? * Field can be switch to another type (only sb/msb) * Shared Fields * Import/Export XML * 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? * Artifacts * Export/import CSV * What does 'None' mean for this field? * Default value * 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 * Reports * 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 * Angular * 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