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-3BiecOEc0x3xkfiDbNyVVTK5%3DH_zZHKkSdPenUTKLfTr%3D8Q%40mail.gmail.com.
