(replies inline)
On Wed, 22 Jan 2020 at 01:24, Michael Cirioli <[email protected]> wrote: > (moving this discussion from https://github.com/jenkinsci/jep/pull/261 in > order to have more visibility) > > - 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 > > I think that configure should just be above system read, but I don't know how that would affect the UX of CONFIGURE > > - 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. > > Hopefully unneeded > > - 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. > > Another thought I had was updating the jelly tags to allow to take an array, and add a method called 'hasAnyPermission', which would at least solve the view part > 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 > <https://groups.google.com/d/msgid/jenkinsci-dev/1088605f-a0fc-460b-8a44-7f07a4eb7b2b%40googlegroups.com?utm_medium=email&utm_source=footer> > . On Wed, 22 Jan 2020 at 15:28, Jesse Glick <[email protected]> wrote: > On Tue, Jan 21, 2020 at 8:24 PM Michael Cirioli <[email protected]> > wrote: > > Consider the case where a user has both Jenkins.CONFIGURE and > Jenkins.SYSTEM_READ - what would the expected experience be? > > > > ..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 you split parts of the `/configure` page into an `/administer` > page, rather than conditionally hiding them, then I think this could > be solved in a different way that feels more in line with existing > patterns: > I'm not sure this would work well for read only support, what items on the existing configure page would you not want to expose? > > · If you have `ADMINISTER`, `/administer` has a *Save* (and *Apply*) > button. Else, if you have `SYSTEM_READ`, it does not. If you have > neither, it cannot be displayed at all. > · If you have `CONFIGURE`, `/configure` has *Save*. If you have > `VIEW_CONFIGURATION` (at global scope?), it does not. If you have > neither, it cannot be displayed at all. > > an ideal solution should support any additional permissions that may find > their way into Jenkins in the future > > Do we really want to be adding complex new permission options? The > Jenkins permission system is way too complex as it stands, making for > a poor UX, and as for Jenkins developers, I at least can barely keep > the intended behavior straight in my head. Many advanced use cases > would be better handled via `configuration-as-code` plus other > tooling, processes, or policies (GitHub’s `CODEOWNERS`, for example). > > Absolutely agree with handling configuration via `configuration-as-code` or other tools, but I do think we're missing a lot of information that is useful to users to either: 1. contribute to the plugins / configuration of their instance. 2. debug why their build has an issue 3. debug / solve an issue faster with why their agent isn't starting (cloud logs, agent startup logs etc) Just thinking of ci.jenkins.io if some of the information above were surfaced to a wider audience I believe we would be able to have a more stable CI instance / information available far quicker Many thanks for all feedback Tim > -- > 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/CANfRfr1fvvuZiiHRNH7mD6kPMV%3DtuC1EJPb3x8r71SmwR%3DK1kw%40mail.gmail.com > . > -- 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/CAH-3BifDS4YACEMsON2W5suUhzstksvwer9CRhg2Jimvgpjbng%40mail.gmail.com.
