Tim, I've added a section to our proposed JEP-223 <https://github.com/jenkinsci/jep/tree/master/jep/224> committing to work with you on the Jenkins.SYSTEM_READ effort so that we can find a way to provide both of these features to the user in a way that makes sense and provides a non-confusing experience.
thanks -mike On Thursday, January 23, 2020 at 2:57:00 PM UTC-5, Tim Jacomb wrote: > > > > (replies inline) > > > > On Wed, 22 Jan 2020 at 01:24, Michael Cirioli <[email protected] > <javascript:>> 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] <javascript:>. >> 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] > <javascript:>> wrote: > >> On Tue, Jan 21, 2020 at 8:24 PM Michael Cirioli <[email protected] >> <javascript:>> 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] <javascript:>. >> 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/81fe1458-9660-4dd5-a538-f0f720708b45%40googlegroups.com.
