An update on system read, Wadeck and I took a look at making the UI look read only, rather than just removing the apply buttons, and we got it working.
Screenshots are in the PR description: https://github.com/jenkinsci/jenkins/pull/4149 Please take a look and provide any feedback you have Thank Tim On Mon, 27 Jan 2020 at 17:48, Tim Jacomb <[email protected]> wrote: > Perfect thanks Michael > > On Mon, 27 Jan 2020 at 15:21, Michael Cirioli <[email protected]> > wrote: > >> 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]> >>> 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/81fe1458-9660-4dd5-a538-f0f720708b45%40googlegroups.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/81fe1458-9660-4dd5-a538-f0f720708b45%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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-3BidRibVuYsx-rpqccRCqmhJ%2Bi%3D7WqCgjpKVaBy8Osz6mtg%40mail.gmail.com.
