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 <mcir...@cloudbees.com > <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 jenkin...@googlegroups.com <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 <jgl...@cloudbees.com > <javascript:>> wrote: > >> On Tue, Jan 21, 2020 at 8:24 PM Michael Cirioli <mcir...@cloudbees.com >> <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 jenkin...@googlegroups.com <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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/81fe1458-9660-4dd5-a538-f0f720708b45%40googlegroups.com.
