(moving this discussion from https://github.com/jenkinsci/jep/pull/261 in order to have more visibility)
JEP-223 : "Limited Administer" permission <https://github.com/jenkinsci/jep/tree/master/jep/223> and JEP-0000 : System read permission <https://github.com/timja/jep/tree/jep-system-read/jep/0000> propose introducing new permission types aimed at solving specific problems for a Jenkins administrator. JEP-223 provides for a new permission that allows an administrator to delegate the ability to configure non-security aspects of a Jenkins instance, while JEP-0000 (System read permission) will allow a non-administrator user to view (but not change) many configuration options that would normally only be visible to a user who has the overall Jenkins.ADMINISTER permission. Taken individually, either of these proposed changes provides a fairly straightforward user experience. However, assuming both are eventually accepted, the user experience will not be so clear. Consider the case where a user has both Jenkins.CONFIGURE and Jenkins.SYSTEM_READ - what would the expected experience be? - Both proposals expect plugins to override getRequiredPermission() in order to determine what should be shown to a user. The intention of JEP-0000 is that _most_ items would be shown (read-only) to a user, This will potentially create a conflict with JEP-223, as a user may be shown things that can be changed by a user with Jenkins.CONFIGURE, but the changes may not be persisted because of the Jenkins.SYSTEM_READ changes. - If a user has both Jenkins.CONFIGURE and Jenkins.SYSTEM_READ, should they be able to view some things they can't configure, and being able to change some things that a user who only has Jenkins.SYSTEM_READ would normally only be able to view? I don't currently have a proposal on how to best address this, but I do have some ideas.... - Provide a mean for permissions to specify precedence (ie. CONFIGURE is less restrictive than SYSTEM_READ). This is different than the current *implies(...)* because an administrator may not want a user with the CONFIGURE permission to automatically also have SYSTEM_READ - Add logic to the matrix-auth plugin such that some permission types are mutually exclusive. ie. if you grant CONFIGURE, you can't also grant SYSTEM_READ. - Allow getRequiredPermission() to return a list of permissions, and tailor the user experience for any given plugin with custom logic. This may be more error prone to maintain, and would need to be well thought out enough so that any plugins that are unaware of the new permissions behave in a predictable way. Although the above thoughts are focused on the two new permissions currently being proposed, an ideal solution should support any additional permissions that may find their way into Jenkins in the future. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1088605f-a0fc-460b-8a44-7f07a4eb7b2b%40googlegroups.com.
