Edgewall Software

Changes between Version 10 and Version 11 of TracDev/Proposals/BatchModification


Ignore:
Timestamp:
Oct 29, 2010, 9:39:08 AM (12 years ago)
Author:
Christian Boos
Comment:

my 2 cents about the TRAC_BATCH_MODIFY purpose

Legend:

Unmodified
Added
Removed
Modified
  • TracDev/Proposals/BatchModification

    v10 v11  
    3333
    3434  (osimons) I do not like the separate permission, and to me it makes no sense. If you are allowed to change each ticket, then surely you should be allowed to modify them through a batch update? If the feature is to become an integrated part of Trac, then the `TRAC_BATCH_MODIFY` permission just adds complexity and administrative overhead.
    35  
    36   (!CuriousCurmudgeon) That was my initial thought too, but experience has shown me that many teams want these permissions to be separate. The biggest reason seems to be auditing requirements.
     35    (!CuriousCurmudgeon) That was my initial thought too, but experience has shown me that many teams want these permissions to be separate. The biggest reason seems to be auditing requirements.
     36      (cboos) Another way to look at it is about the amount of "harm" that can be done to a project, intentionally or simply by misguided people: if someone with a simple TICKET_MODIFY could use the batch modify facility, he could in two or three requests put the entire project in a pretty unusable state (e.g. reset all open tickets to "low" priority and "unscheduled" for example). As we don't have yet a "batch undo" facility (that would be hard I suppose), the only way to prevent this is to reserve this feature to trusted people, like we do for TICKET_ADMIN. So I think it's only in the case when a project needs to differentiate between "full" TICKET_ADMIN and people able to modify batches of tickets that the new permission would be useful, otherwise in most cases TICKET_ADMIN should be enough.
    3737
    3838=== Workflows ===