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: · 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). -- 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.
