> The other thing you will want to do so that you can do joins against privilege > id columns in the Bugzilla database schema). > column name can be called "id" (this is also consistent with the names of other > I agree with Paul in general, with the exception that I think the "status_id" That is just a few, I probably could go on longer but I don't want to sound too Having to type 'bug_id' why all the extra s's from plural table names?Ĥ. Stored in a table called 'persons' or 'people'. It's privilege system uses tables named 'user' not The object would probably be a list of bug objects. Would have a 'bug' class, not a 'bugs' class. Raw data, it's more crucial that table names be the same as class names. as databases are used more and more as storage for objects instead of just > why the problem with plural table names?ġ. (in priv_required) but that's probably going to have to be another bug. It would also be good if the privilege system used id numbers instead of text No point in creating new features thatĪre MySQL dependant while there is work going on to make this work with other
That andĮnum's are bad and only exist in MySQL. I did it because Iĭon't quite understand what they are used for, so that is my bad. I also left off the two enum columns from the "status" table. The whole database replacing every instance of RESOLVED to TAKENCAREOF.
#Bugzilla workflow customization code
Status can be renamed without there needing to be code that angerly goes throug Note the use of id numbers instead of the text name of the status. | 1 | 2 | (canconfirm|editbugs|owner|qa) | | status_id | avail_status | privs_required | | 3 | ASSIGNED | This bug is not yet resolved, but. | 2 | NEW | This bug has recently been added. | 1 | UNCONFIRMED | This bug has recently been added. That I better give my own suggestion right :-) I would recommend tables along Of plurals for table names also frightens me but not quite as much. The use of character fields instead of integer id fields frightens me. Prevent going to unconfirmed except from other unconfirmed. Prevent automatic transitions from going to open to non-open and vice versa, We could do various sanity checks on transitions: Manually, when it should occur automatically, when it should wake upĪutomatically and when it should be able to be woken up manually. We need to know when it can be put to sleep (either put one status on the status table for each unconfirmed open status orĪlso, automatic sleep/wakeups like ASLEEP ( bug #8527) and REMIND ( bug #65402)Ĭould hopefully be in this scheme. We need to handle automatic transitions somehow. Whether the bug gets confirmed by the transition, whether the resolution needs We need to automatically generate the actions from here, including: UNCONFIRMED transition is not present for example. I ripped this from the old bug, it is not entirely correct, a RESOLVED -> | VERIFIED | CLOSED | (editbugs|owner|qa) | | VERIFIED | REOPENED | (editbugs|owner|qa|reporter) |
| REOPENED | RESOLVED | (editbugs|owner|qa|reporter) | | REOPENED | ACCEPTED | (editbugs|owner) | | REOPENED | ASSIGNED | (editbugs|owner|qa) | | RESOLVED | CLOSED | (editbugs|owner|qa) | | RESOLVED | VERIFIED | (editbugs|qa|reporter) | | RESOLVED | REOPENED | (editbugs|owner|qa|reporter) | | ACCEPTED | RESOLVED | (editbugs|owner|qa|reporter) | | ASSIGNED | RESOLVED | (editbugs|owner|qa|reporter) | | ASSIGNED | ACCEPTED | (editbugs|owner) | | NEW | RESOLVED | (editbugs|owner|qa|reporter) | | UNCONFIRMED | RESOLVED | (editbugs|owner|qa|reporter) | | UNCONFIRMED | ACCEPTED | (editbugs|owner) | | UNCONFIRMED | ASSIGNED | (editbugs|owner|qa) | | UNCONFIRMED | NEW | (canconfirm|editbugs|owner|qa) | | state_now | avail_states | privs_required | This will get rid of an enumeration, but alsoĪllow status renaming of statuses, setting of permissions on transitions, and
0 kommentar(er)
