(moving this discussion from https://github.com/jenkinsci/jep/pull/261 in order to have more visibility)
I don't currently have a proposal on how to best address this, but I do have some ideas....
- 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?
- 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
- 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.
- 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.
--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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1088605f-a0fc-460b-8a44-7f07a4eb7b2b%40googlegroups.com.
On Tue, Jan 21, 2020 at 8:24 PM Michael Cirioli <mcir...@cloudbees.com> 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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1fvvuZiiHRNH7mD6kPMV%3DtuC1EJPb3x8r71SmwR%3DK1kw%40mail.gmail.com.
(moving this discussion from https://github.com/jenkinsci/jep/pull/261 in order to have more visibility)JEP-223 : "Limited Administer" permission and JEP-0000 : System read permission propose introducing new permission types aimed at solving specific problems for a Jenkins administrator. JEP-223 provides for a new permission that allows an administrator to delegate the ability to configure non-security aspects of a Jenkins instance, while JEP-0000 (System read permission) will allow a non-administrator user to view (but not change) many configuration options that would normally only be visible to a user who has the overall Jenkins.ADMINISTER permission.Taken individually, either of these proposed changes provides a fairly straightforward user experience. However, assuming both are eventually accepted, the user experience will not be so clear. Consider the case where a user has both Jenkins.CONFIGURE and Jenkins.SYSTEM_READ - what would the expected experience be?
- 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
- 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.
(replies inline)
On Wed, 22 Jan 2020 at 01:24, Michael Cirioli <mcir...@cloudbees.com> wrote:(moving this discussion from https://github.com/jenkinsci/jep/pull/261 in order to have more visibility)I don't currently have a proposal on how to best address this, but I do have some ideas....
- 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?
- 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.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@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.