In order to be included in Permission.getAll(), a Permission needs to be initialized in a static block inside an @Extension or otherwise definitely loaded during startup.

      The visible symptom is that you might configure an authorization strategy such as matrix with all permissions granted, then go back later and see SCM/Tag missing, because it was unknown earlier.

          [JENKINS-17200] SCM.TAG permission not eagerly loaded

          Jesse Glick added a comment -

          Would be better to have some kind of declarative registration for permissions. Could handle default grant status for things like JENKINS-15484 as well. Some other messiness: hudson.security.WipeOutPermission=true; hudson.security.ArtifactsPermission=true; and of course https://wiki.jenkins-ci.org/display/JENKINS/Extended+Read+Permission+Plugin is well known.

          https://github.com/jenkinsci/embeddable-build-status-plugin/pull/4/files#r4421926 claims that at least for Project-based Matrix Authorization Strategy even loading the permission in an @Extension does not suffice—perhaps because it tries to load the matrix before extensions are loaded?

          Jesse Glick added a comment - Would be better to have some kind of declarative registration for permissions. Could handle default grant status for things like JENKINS-15484 as well. Some other messiness: hudson.security.WipeOutPermission=true ; hudson.security.ArtifactsPermission=true ; and of course https://wiki.jenkins-ci.org/display/JENKINS/Extended+Read+Permission+Plugin is well known. https://github.com/jenkinsci/embeddable-build-status-plugin/pull/4/files#r4421926 claims that at least for Project-based Matrix Authorization Strategy even loading the permission in an @Extension does not suffice—perhaps because it tries to load the matrix before extensions are loaded?

          Jesse Glick added a comment -

          Blocking JENKINS-16502, perhaps.

          Jesse Glick added a comment - Blocking JENKINS-16502 , perhaps.

          Matt Sicker added a comment -

          What if we had a sort of PermissionProvider meta-inf service which, when invoked, returns a collection of permissions to register. Due to initialization ordering, this might not be the best class to use a whiteboard pattern on (which is essentially what the existing extension-based permission model is doing).

          Matt Sicker added a comment - What if we had a sort of PermissionProvider meta-inf service which, when invoked, returns a collection of permissions to register. Due to initialization ordering, this might not be the best class to use a whiteboard pattern on (which is essentially what the existing extension-based permission model is doing).

          Matt Sicker added a comment -

          For this issue, right now I have a proposal to make permissions declarative and lazily load them. See here: https://github.com/jenkinsci/jenkins/pull/3696

          Matt Sicker added a comment - For this issue, right now I have a proposal to make permissions declarative and lazily load them. See here: https://github.com/jenkinsci/jenkins/pull/3696

          Matt Sicker added a comment -

          Refactored that proposal into a standalone PR: https://github.com/jenkinsci/jenkins/pull/3713

          Matt Sicker added a comment - Refactored that proposal into a standalone PR: https://github.com/jenkinsci/jenkins/pull/3713

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: