Mercurial > hg > savane-forge
view doc/savane3_trackers.txt @ 337:af82331e34ca
Python 2.5 compat
author | Sylvain Beucler <beuc@beuc.net> |
---|---|
date | Sun, 22 Aug 2010 23:45:00 +0200 |
parents | 7234fcf49cc0 |
children |
line wrap: on
line source
The static definition in savane.trackers.defs is generated using scripts/tracker_gendefs.py. Trackers are described in Savane3 using a 3-level structure: - Field : definition - Field usage : additional definition (group=100) and partial overlay (override values) infrastructure (group!=100) - Field value : possible values for dropdown (<select>) widgets (default values and overlays) In tracker.models we now have a single structure for field definition, which is pretty much static in Savane3 except that Savannah has historical inconsistencies: mysql> SELECT bug_field_id, group_id, use_it, show_on_add, show_on_add_members, place, id FROM temp_bugs_field_usage WHERE id IN (SELECT id FROM (SELECT B.id FROM temp_bugs_field_usage A, temp_bugs_field_usage B WHERE A.bug_field_id = B.bug_field_id AND A.group_id = B.group_id AND (A.use_it != B.use_it OR A.show_on_add != B.show_on_add OR A.show_on_add_members != B.show_on_add_members OR A.place != B.place)) AS temp) AND group_id=100 ORDER BY bug_field_id; +--------------+----------+--------+-------------+---------------------+-------+-----+ | bug_field_id | group_id | use_it | show_on_add | show_on_add_members | place | id | +--------------+----------+--------+-------------+---------------------+-------+-----+ | 102 | 100 | 1 | 1 | 1 | 200 | 7 | | 102 | 100 | 1 | 0 | 1 | 200 | 73 | | 107 | 100 | 0 | 1 | 1 | 300 | 12 | | 107 | 100 | 1 | 1 | 1 | 300 | 78 | | 211 | 100 | 1 | 0 | 1 | 200 | 25 | | 211 | 100 | 0 | 0 | 0 | 250 | 91 | | 216 | 100 | 1 | 2 | 0 | 560 | 30 | | 216 | 100 | 0 | 0 | 0 | 560 | 160 | +--------------+----------+--------+-------------+---------------------+-------+-----+ 8 rows in set (0.11 sec) mysql> SELECT bug_field_id, field_name, required FROM savane_old.bugs_field WHERE bug_field_id IN (102, 107, 211, 216); +--------------+------------------+----------+ | bug_field_id | field_name | required | +--------------+------------------+----------+ | 102 | severity | 0 | | 107 | bug_group_id | 0 | | 211 | priority | 1 | | 216 | originator_email | 0 | +--------------+------------------+----------+ 4 rows in set (0.00 sec) Not: if we want to convert trackers from other forges, we may need the extra flexibility of defining site-wide default for a given tracker. Consequently let's keep in-base definition of tracker defaults. Field definition is static until the field themselves are dynamic (if ever). Merging the fields definition and their default values was still beneficial as it allowed reworking the data structure and removing duplicate columns (display/custom_display, etc.). - - - - - - - Here is a description of the Savane_3_ data structure, used as reference to build this new implementation: - Field Site-wide field definitions for the 4 trackers: 70 fields each, + 2 more for 'task' ('planned_starting_date', 'planned_close_date'), 1 more for 'patch' ('revision tag' - but it's actually a bogus entry in patch_field as there's nowhere to store its item value). The field item values are stored in the 'bugs'/'patch'/etc. table, which has 73 columns (1 for the IP address + 1 for spamscore + 1 col for each 72 Field - 1 for 'comment_type_id' which is not stored). Fields are not necessarily displayed or/and editable ('bug_id', 'group_id') but their definition may be used in other contexts, such as list sort order. Most fields cannot be redefined (such as display_type or scope). Usually fields that can be redefined are in FieldUsage, where an entry with special group_id=100 contains the default value. However some of the fields in this class ('display_size', 'empty_ok', and 'keep_history') can be redefined through similar fields in FieldUsage - in which case it's not clear whether the default value is: - in Field(tracker_id, field_name) - or FieldUsage(tracker_id, group_id=100, field_name) At first glance it's defined here, all related values in FieldUsage are set to NULL. Field definition is almost identical for all trackers (59 fields / 73 have the same configuration). They could be regrouped. SELECT COUNT(*) FROM ( SELECT field_name FROM bugs_field UNION SELECT field_name FROM patch_field UNION SELECT field_name FROM support_field UNION SELECT field_name FROM task_field ) subquery; => 73 SELECT COUNT(*), field_name FROM ( SELECT * FROM bugs_field UNION SELECT * FROM patch_field UNION SELECT * FROM support_field UNION SELECT * FROM task_field ) subquery GROUP BY field_name HAVING COUNT(*) > 1; -- Only slight differences in description , except for these 2: +----------+---------------------+ | COUNT(*) | field_name | +----------+---------------------+ ... | 4 | priority | -- (required=1,empty_ok=0)(bugs,task) | (required=0,empty_ok=1)(patch,support) | 2 | resolution_id | -- (required=1)(bugs,task) | (required=0)(patch,support) ... +----------+---------------------+ 14 rows in set (0.00 sec) So we could just set required=0,empty_ok=1 for those 2. - Field usage: Field configuration overlay for each group group == 100 means default Differences between trackers for default values: SELECT COUNT(*) FROM ( SELECT bug_field_id FROM bugs_field_usage UNION SELECT bug_field_id FROM patch_field_usage UNION SELECT bug_field_id FROM support_field_usage UNION SELECT bug_field_id FROM task_field_usage ) subquery; => 73 SELECT bug_field_id, COUNT(*) FROM ( SELECT * FROM bugs_field_usage WHERE group_id=100 UNION SELECT * FROM patch_field_usage WHERE group_id=100 UNION SELECT * FROM support_field_usage WHERE group_id=100 UNION SELECT * FROM task_field_usage WHERE group_id=100 ) subquery GROUP BY bug_field_id HAVING COUNT(*) > 2; +--------------+----------+ | bug_field_id | COUNT(*) | +--------------+----------+ | 92 | 2 | submitted_by | 102 | 2 | severity | 107 | 2 | bug_group_id | 201 | 2 | platform_version_id | 206 | 2 | hours | 211 | 4 | priority | 216 | 2 | originator_email | 220 | 2 | percent_complete +--------------+----------+ 92 -> (use_it=0)(patch,support) | (use_it=1)(bugs,task) 102 -> (use_it,show_on_add,show_on_add_members=0)(patch,task) | (use_it,show_on_add,show_on_add_members=1)(bugs,support) 107 -> (show_on_add,show_on_add_members=0)(patch,support) | (show_on_add,show_on_add_members=1)(bugs,task) [but use_it=0] 201 -> (use_it,show_on_add,show_on_add_members=0)(bugs,patch,task) | (use_it,show_on_add,show_on_add_members=1)(support) 206 -> (use_it,show_on_add,show_on_add_members=0)(bugs,patch,support) | (use_it,show_on_add,show_on_add_members=1)(task) 211 -> (show_on_add,show_on_add_members,place) bugs: 0,1,200 patch: 1,1,150 support: 0,0,150 task: 1,1,200 216 -> (use_it,show_on_add=0)(task) | (use_it=1,show_on_add=2)(bugs,patch,support) 220 -> (use_it,show_on_add_members=0)(bugs,patch,support) | (use_it,show_on_add_members=1)(task) - Field values: Choices overlay for a select-box (SB) field of a specific group Values that change between trackers: SELECT bug_field_id,group_id,value_id,value FROM bugs_field_value WHERE group_id=100 UNION SELECT bug_field_id,group_id,value_id,value FROM patch_field_value WHERE group_id=100 UNION SELECT bug_field_id,group_id,value_id,value FROM support_field_value WHERE group_id=100 UNION SELECT bug_field_id,group_id,value_id,value FROM task_field_value WHERE group_id=100 ORDER BY bug_field_id,group_id,value_id; | 108 | 100 | 1 | Fixed | bugs | 108 | 100 | 1 | Done | patch,support,task | 108 | 100 | 3 | Wont Fix | bugs | 108 | 100 | 3 | Wont Do | patch,support | 108 | 100 | 3 | Cancelled | task Savannah and Gna!-specific: | 201 | 100 | 120 | Microsoft Windows | bugs,task | 201 | 100 | 120 | *BSD | support patch: (None) | 201 | 100 | 130 | *BSD | bugs,task | 201 | 100 | 130 | Microsoft Windows | support patch: (None) => To regroup: put "Wont Do" everywhere, "Done" everywhere, and manually revert woe/bsd in support.items