Edgewall Software

Changes between Initial Version and Version 2 of Ticket #12719


Ignore:
Timestamp:
Mar 11, 2017, 9:44:23 AM (4 years ago)
Author:
Ryan J Ollos
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #12719 – Description

    initial v2  
    1 These ideas were generated from gmessage:trac-users:T-bb2GAvqxI/tFs0_7yQDAAJ:
    2 * By default users are allowed to edit their own comments, and I think in most cases it would make sense to allow users with `TICKET_CHGPROP` to edit their own ticket descriptions. We could allow users to edit their own ticket descriptions through a permission policy, thus making it easy for Trac sites that don't want the behavior to change it by replacing the permission policy or adding a different policy earlier in the list of permission policies.
    3 * #10909 requests a permission for allowing users to edit their own comments. Alternatively, we could just move the //edit own comment// behavior to a permission policy, which can then be replaced by sites that want different behavior.
    4 * `ReadonlyWikiPolicy` is very specific. If a site wants to replace the policy, for example adding a custom permission for editing readonly pages, a new policy with the same name needs to be implemented (due to [browser:tags/trac-1.2/trac/wiki/web_ui.py@:567#L558]). It would be better to allow an arbitrary name.
     1These ideas are generated from gmessage:trac-users:T-bb2GAvqxI/tFs0_7yQDAAJ:
     2* By default users are allowed to edit their own comments, and I think in most cases it makes sense to allow users with `TICKET_CHGPROP` to edit their own ticket description. We could allow users to edit their own ticket descriptions through a permission policy, thus making it easy for Trac sites that don't want the behavior to change it by replacing the permission policy or adding a different policy earlier in the list of permission policies.
     3* #10909 requests a permission for allowing a user to edit their own comment. Alternatively, we could just move the //edit own comment// behavior to a permission policy, which can then be replaced by sites that want different behavior.
     4* `ReadonlyWikiPolicy` is very specific. Also, if a site wants to replace the policy, for example adding a custom permission for editing readonly pages, a new policy with the same name needs to be implemented (due to [browser:tags/trac-1.2/trac/wiki/web_ui.py@:567#L558]). It would be better to allow an arbitrary policy name, and by default to have a general //wiki// policy that implements the readonly behavior. The wiki policy can be extended in the future with additional rules for the wiki realm.
    55
    66The proposed changes implement the described rules in two policies, `DefaultTicketPolicy` and `DefaultWikiPolicy`, which can then be extended in the future with additional rules for the ticket and wiki realms. I like the idea of having specific policies associated with realms, and moving the aforementioned behaviors out of the Module classes and into permission policies.