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

Timestamp:

Oct 29, 2010, 9:39:08 AM (13 years ago)

Author:

Christian Boos

Comment:

my 2 cents about the TRAC_BATCH_MODIFY purpose

TracDev/Proposals/BatchModification

@@ -33 +33 @@
 
   (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.
-  
-  (!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.
+    (!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.
+      (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.
 
 === Workflows ===