Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-14713

Cancel permission is granted for users having build permission

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Blocker
    • Resolution: Fixed
    • Component/s: core
    • Labels:
    • Environment:
      Jenkins 1.465
    • Similar Issues:

      Description

      I expected that people need to have the "Cancel" permission to be able to cancel a build. That's right, unless they have the "Build" permission.
      I would like to be able to give "build" permission to some people without allowing them to abort a build. What do you think of it?

        Attachments

          Issue Links

            Activity

            Hide
            hangsu Hangsu Ma added a comment -

            The script in the link below will explicit grant Cancel permission to user with Build permission. So the configuration will be compatible after this change.
            https://wiki.jenkins-ci.org/x/fAAhB

            Show
            hangsu Hangsu Ma added a comment - The script in the link below will explicit grant Cancel permission to user with Build permission. So the configuration will be compatible after this change. https://wiki.jenkins-ci.org/x/fAAhB
            Hide
            hangsu Hangsu Ma added a comment -
            Show
            hangsu Hangsu Ma added a comment - code change in jenkins can be find here: https://github.com/hangsuma/jenkins/commit/1d0be0016bc498810579d8494c87bbd2922893b3
            Hide
            hangsu Hangsu Ma added a comment -
            Show
            hangsu Hangsu Ma added a comment - pull request here: https://github.com/jenkinsci/jenkins/pull/882
            Hide
            kerrhome Shannon Kerr added a comment -

            Can users have permission to cancel their own builds but not the builds of others? This is what I thought +Build and -Cancel permissions would do, but that's not the case.

            When I gave a user build permission, I see users can cancel not just their own, but they can cancel any build they want.

            I think it should be that If I grant someone "cancel" permission, they could cancel any build for the system or for the project since we use per-project permissions. When I haven't given them cancel permission, I'm not sure why they can cancel the build of anyone.

            Show
            kerrhome Shannon Kerr added a comment - Can users have permission to cancel their own builds but not the builds of others? This is what I thought +Build and -Cancel permissions would do, but that's not the case. When I gave a user build permission, I see users can cancel not just their own, but they can cancel any build they want. I think it should be that If I grant someone "cancel" permission, they could cancel any build for the system or for the project since we use per-project permissions. When I haven't given them cancel permission, I'm not sure why they can cancel the build of anyone.
            Hide
            walterk82 Walter Kacynski added a comment -

            Kohsuke, can you comment on the original design goal of the build/cancel permission relationship?

            Show
            walterk82 Walter Kacynski added a comment - Kohsuke, can you comment on the original design goal of the build/cancel permission relationship?
            Hide
            hu3b10q7 Csaba Gyorfi added a comment -

            Hello,

            I am using Jenkins v1.519 where this correction should be included already. But: I can not remove the cancel permission for the users. Even if I check out the check box "Cancel" at Project-Based security matrix, users can cancel jobs.
            Is this a new error or related to this issue?
            Background: we use clearcase and snapshot views. Updating a snapshot view can take about 15-20 mins. If a user cancels a job during the update phase, the update process itself will not be stopped, and a second job can not be started or queued. Therefore I decided to remove the cancel permission completely (even for own jobs), but it has no effect.

            Show
            hu3b10q7 Csaba Gyorfi added a comment - Hello, I am using Jenkins v1.519 where this correction should be included already. But: I can not remove the cancel permission for the users. Even if I check out the check box "Cancel" at Project-Based security matrix, users can cancel jobs. Is this a new error or related to this issue? Background: we use clearcase and snapshot views. Updating a snapshot view can take about 15-20 mins. If a user cancels a job during the update phase, the update process itself will not be stopped, and a second job can not be started or queued. Therefore I decided to remove the cancel permission completely (even for own jobs), but it has no effect.
            Hide
            kerrhome Shannon Kerr added a comment -

            Thanks Walter, yes Kohsuke, I would like to understand the original design goal.

            Show
            kerrhome Shannon Kerr added a comment - Thanks Walter, yes Kohsuke, I would like to understand the original design goal.
            Hide
            nickolayr Nickolay Rumyantsev added a comment -

            Is there any progress with this issue?

            Show
            nickolayr Nickolay Rumyantsev added a comment - Is there any progress with this issue?
            Hide
            ndesjardins Nicolas Desjardins added a comment -

            We just worked around this to keep people from inappropriately killing builds and messing up workspaces. We have Jenkins hosted behind nginx, so in the site config for jenkins, I added this directive:

            location ~ "/stop$"

            { return 401; }

            This will return 401 (unauthorized) for anyone attempting to stop a build.

            Show
            ndesjardins Nicolas Desjardins added a comment - We just worked around this to keep people from inappropriately killing builds and messing up workspaces. We have Jenkins hosted behind nginx, so in the site config for jenkins, I added this directive: location ~ "/stop$" { return 401; } This will return 401 (unauthorized) for anyone attempting to stop a build.
            Hide
            jonmr Jon Radon added a comment -

            I would also like to see this fixed.

            Show
            jonmr Jon Radon added a comment - I would also like to see this fixed.
            Hide
            dedekind Artem Bityutskiy added a comment -

            Is Jenkins that dead project that serious bugs like that do not grab attention of core developers for years?

            Show
            dedekind Artem Bityutskiy added a comment - Is Jenkins that dead project that serious bugs like that do not grab attention of core developers for years?
            Hide
            danielbeck Daniel Beck added a comment -

            Artem Bityutskiy:

            serious bugs like that

            It's deliberate behavior as can be seen in the original pull request that originally added the Cancel permission:
            https://github.com/jenkinsci/jenkins/pull/373/files#diff-177cd545e24a34ac370093ddf2e4d28cR231

            That BUILD parameter to the constructor means that Build implies Cancel, so whoever has Build gets Cancel as well (the UI of the matrix-auth plugin doesn't show that, unfortunately – it's similar to Administer implying pretty much every other permission). While a case can be made that it be changed, that hardly constitutes a 'serious bug'. It's more like a feature that doesn't work quite like you expect it to.

            FWIW if not having a Cancel permission independent of Build is as serious of an issue for you as Jenkins no longer starting or scheduling any jobs – which is what Blocker means, more severe than data loss or crashes – you probably took a wrong turn in setting up your system somewhere.

            do not grab attention of core developers for years?

            Not sure where you got this impression. Jesse Glick and I discussed the PR 882 linked above for a bit as you can see there. Jesse is understandably worried about breaking all installs that rely on the current behavior, so PR 882 is probably an insufficient approach.

            Show
            danielbeck Daniel Beck added a comment - Artem Bityutskiy : serious bugs like that It's deliberate behavior as can be seen in the original pull request that originally added the Cancel permission: https://github.com/jenkinsci/jenkins/pull/373/files#diff-177cd545e24a34ac370093ddf2e4d28cR231 That BUILD parameter to the constructor means that Build implies Cancel, so whoever has Build gets Cancel as well (the UI of the matrix-auth plugin doesn't show that, unfortunately – it's similar to Administer implying pretty much every other permission). While a case can be made that it be changed, that hardly constitutes a 'serious bug'. It's more like a feature that doesn't work quite like you expect it to. FWIW if not having a Cancel permission independent of Build is as serious of an issue for you as Jenkins no longer starting or scheduling any jobs – which is what Blocker means, more severe than data loss or crashes – you probably took a wrong turn in setting up your system somewhere. do not grab attention of core developers for years? Not sure where you got this impression. Jesse Glick and I discussed the PR 882 linked above for a bit as you can see there. Jesse is understandably worried about breaking all installs that rely on the current behavior, so PR 882 is probably an insufficient approach.
            Hide
            dedekind Artem Bityutskiy added a comment - - edited

            Daniel, thanks for constructive reply despite a bit provocative message.

            Short answer:
            1. It looks like I might have commented in a wrong JIRS issue.
            2. The serious bug I referred to is the problem that user A can cancel jobs of user B, and I thought it is related to this bug.
            3. May be a bit more JIRA management would benefit the project, won'tfix bugs could be closed right away.

            Longer answer.

            So the problem I experience is that users may cancel each other's job. We already saw several times that one user accidentally presses the red cross for a wrong job and aborts other's jobs. Now, I thought that I would just prevent anyone from cancelling anything by removing the "cancel" rights (a workaround), but it did not work - anyone who can submit a job has a cancel right and can kill anyone's job. This is the serious bug I referred to. To put it differently, anyone can kill others work, and an obvious workaround does not work (by design, apparently). This JIRA issue looked related, thus my comment. Sorry if this is a wrong place.

            VS "build includes cancel". I see the logic, but should admit it is confusing, because cancel without build is generally not very useful, while build without cancel is generally useful, so casual users naturally think of the latter. Indeed, I do want to control whether my users can cancel their jobs or not, just like whether they can submit them.

            VS "we discussed this with Jesse": thanks, although I should say the conversation is not easy to find for a casual user like me, it did not pop up in my google requests. So your users look at the JIRA issue, which goes on for several years, and the impression they have is just as I described: is the project alive? Just a suggestion: I think some more JIRA management would benefit the project. E.g., if core developers are not going to fix this issue, why not to be explicit and close it? This is not the only JIRA issue which needs some care, in my opinion.

            Show
            dedekind Artem Bityutskiy added a comment - - edited Daniel, thanks for constructive reply despite a bit provocative message. Short answer: 1. It looks like I might have commented in a wrong JIRS issue. 2. The serious bug I referred to is the problem that user A can cancel jobs of user B, and I thought it is related to this bug. 3. May be a bit more JIRA management would benefit the project, won'tfix bugs could be closed right away. Longer answer. So the problem I experience is that users may cancel each other's job. We already saw several times that one user accidentally presses the red cross for a wrong job and aborts other's jobs. Now, I thought that I would just prevent anyone from cancelling anything by removing the "cancel" rights (a workaround), but it did not work - anyone who can submit a job has a cancel right and can kill anyone's job. This is the serious bug I referred to. To put it differently, anyone can kill others work, and an obvious workaround does not work (by design, apparently). This JIRA issue looked related, thus my comment. Sorry if this is a wrong place. VS "build includes cancel". I see the logic, but should admit it is confusing, because cancel without build is generally not very useful, while build without cancel is generally useful, so casual users naturally think of the latter. Indeed, I do want to control whether my users can cancel their jobs or not, just like whether they can submit them. VS "we discussed this with Jesse": thanks, although I should say the conversation is not easy to find for a casual user like me, it did not pop up in my google requests. So your users look at the JIRA issue, which goes on for several years, and the impression they have is just as I described: is the project alive? Just a suggestion: I think some more JIRA management would benefit the project. E.g., if core developers are not going to fix this issue, why not to be explicit and close it? This is not the only JIRA issue which needs some care, in my opinion.
            Hide
            danielbeck Daniel Beck added a comment -

            Artem Bityutskiy

            To put it differently, anyone can kill others work, and an obvious workaround does not work (by design, apparently). This JIRA issue looked related, thus my comment. Sorry if this is a wrong place.

            This is the correct place (for the workaround, that is). The real issue you're facing however is also pretty much by design, there are currently no per-build permissions. So if you can cancel any builds of a specific project (which gets granted by being able to build), you can cancel all of them. There may be a feature request to only abort someone's own builds around, otherwise please file a new one.

            FWIW I was working on a confirmation dialog for the abort button a while back – that alone may solve your problem, as it's user stupidity rather than deliberate sabotage, right?

            Show
            danielbeck Daniel Beck added a comment - Artem Bityutskiy To put it differently, anyone can kill others work, and an obvious workaround does not work (by design, apparently). This JIRA issue looked related, thus my comment. Sorry if this is a wrong place. This is the correct place (for the workaround, that is). The real issue you're facing however is also pretty much by design, there are currently no per-build permissions. So if you can cancel any builds of a specific project (which gets granted by being able to build), you can cancel all of them. There may be a feature request to only abort someone's own builds around, otherwise please file a new one. FWIW I was working on a confirmation dialog for the abort button a while back – that alone may solve your problem, as it's user stupidity rather than deliberate sabotage, right?
            Hide
            dedekind Artem Bityutskiy added a comment - - edited

            I see, thanks for the answer. Yes, a dialog would be good enough for my specific case, not sure how good of a general solution that would be, though.

            Yes, in my case it is unintentional, not a sabotage. Sometimes it is convenient to cancel a job from the main page, from the left-side "build executor status" frame. And this is where it is sometimes especially easy to press the wrong red cross button.

            Anyway, thanks for your answers, it looks to me that this issue should be closed. I mean, if there is no one who is going to work on it, then "IN PROGRESS" status is very confusing. It is better to clearly state that this is not going to be fixed, may be with an addition that this would not be an easy work, and there is no volunteer currently, etc. I think many people would appreciate the clarity.

            Show
            dedekind Artem Bityutskiy added a comment - - edited I see, thanks for the answer. Yes, a dialog would be good enough for my specific case, not sure how good of a general solution that would be, though. Yes, in my case it is unintentional, not a sabotage. Sometimes it is convenient to cancel a job from the main page, from the left-side "build executor status" frame. And this is where it is sometimes especially easy to press the wrong red cross button. Anyway, thanks for your answers, it looks to me that this issue should be closed. I mean, if there is no one who is going to work on it, then "IN PROGRESS" status is very confusing. It is better to clearly state that this is not going to be fixed, may be with an addition that this would not be an easy work, and there is no volunteer currently, etc. I think many people would appreciate the clarity.
            Hide
            nickolayr Nickolay Rumyantsev added a comment -

            I wonder if it is possible to introduce the discussed permission separation by a plugin or it's only can be done in the Jenkins core?

            Show
            nickolayr Nickolay Rumyantsev added a comment - I wonder if it is possible to introduce the discussed permission separation by a plugin or it's only can be done in the Jenkins core?
            Hide
            danielbeck Daniel Beck added a comment -

            it looks to me that this issue should be closed. I mean, if there is no one who is going to work on it, then "IN PROGRESS" status is very confusing.

            The "In Progress" status is appropriate for an issue with an open pull request. It's just been stalled.

            It is better to clearly state that this is not going to be fixed

            Pointless, as anyone can reopen it with "But I want this" (or "How do you know this will never be done?", and they actually have a point). I've seen this often enough before that I only Won't Fix issues that are clearly not a good idea.

            introduce the discussed permission separation by a plugin

            I don't think this can be done well i.e. in the framework of the permission system (no per-build permissions) except maybe by implementing a full alternative authorization strategy. What would be possible is hiding things on the UI by injecting CSS/JS and block any 'unauthorized' request from going through with a ServletFilter… but who would want that?

            Show
            danielbeck Daniel Beck added a comment - it looks to me that this issue should be closed. I mean, if there is no one who is going to work on it, then "IN PROGRESS" status is very confusing. The "In Progress" status is appropriate for an issue with an open pull request. It's just been stalled. It is better to clearly state that this is not going to be fixed Pointless, as anyone can reopen it with "But I want this" (or "How do you know this will never be done?", and they actually have a point). I've seen this often enough before that I only Won't Fix issues that are clearly not a good idea. introduce the discussed permission separation by a plugin I don't think this can be done well i.e. in the framework of the permission system ( no per-build permissions ) except maybe by implementing a full alternative authorization strategy. What would be possible is hiding things on the UI by injecting CSS/JS and block any 'unauthorized' request from going through with a ServletFilter… but who would want that?
            Hide
            knymer Kim Nyhjem added a comment -

            The reason we have voted for this, is because we have jobs which, if aborted prematurely, leaves servers and/or processes in an undesired or faulted state. The user starting the job is often not aware of the implication of cancelling his/her own job, and would gladly approve a cancel warning dialog.

            So, not malicious, but still a serious issue to us.

            Show
            knymer Kim Nyhjem added a comment - The reason we have voted for this, is because we have jobs which, if aborted prematurely, leaves servers and/or processes in an undesired or faulted state. The user starting the job is often not aware of the implication of cancelling his/her own job, and would gladly approve a cancel warning dialog. So, not malicious, but still a serious issue to us.
            Hide
            dedekind Artem Bityutskiy added a comment - - edited

            Kim, did you notice that here was an nice work-around proposed in this JIRA issue - just prevent users from cancelling jobs on in your web server. Put your Jenkins behind something like nginx or apache (reverse proxy), and filter the */stop URLs out. For an admin who needs the cancel capability, use a different base URL to access the same jenkins server, where you won't have a filter. This way you'll prevent your users from cancelling jobs. Note, I did not try this, but it sounds like a good workaround to me.

            On a separate note, I think I know exactly what you are talking about, our jobs are stateful too. Our jobs must clean-up after themselves in case of aborts, and having the next job to do the clean up is not good enough for us. Currently we clean-up in postbuild (there is an possibility to run a postbuild task only on non-success), but that's not ideal, because users sometimes click the red cross twice, and the postbuild gets aborted on the second click, so the state is not cleaned up. There are also other problems with cancelling jobs we see, like I have the master job, which schedules subjobs and waits for them, users cancel the master job, subjobs keep running and consume resources (we'd like them to be killed instead). I did not find an elegant workaround for these issues (but can imagine some non-elegant ones).

            Anyway, judging from this JIRA issue and from what I read in various discussions, Jenkins is probably just not the right tool for my use-case, which is absolutely fine. I need to investigate different tools or, alternatively, create own custom UI on top of Jenkins REST API, and implement all the limitations/specifics that we need there. Users would use the custom UI, instead of messing with the generic Jenkins UI.

            Show
            dedekind Artem Bityutskiy added a comment - - edited Kim, did you notice that here was an nice work-around proposed in this JIRA issue - just prevent users from cancelling jobs on in your web server. Put your Jenkins behind something like nginx or apache (reverse proxy), and filter the */stop URLs out. For an admin who needs the cancel capability, use a different base URL to access the same jenkins server, where you won't have a filter. This way you'll prevent your users from cancelling jobs. Note, I did not try this, but it sounds like a good workaround to me. On a separate note, I think I know exactly what you are talking about, our jobs are stateful too. Our jobs must clean-up after themselves in case of aborts, and having the next job to do the clean up is not good enough for us. Currently we clean-up in postbuild (there is an possibility to run a postbuild task only on non-success), but that's not ideal, because users sometimes click the red cross twice , and the postbuild gets aborted on the second click, so the state is not cleaned up. There are also other problems with cancelling jobs we see, like I have the master job, which schedules subjobs and waits for them, users cancel the master job, subjobs keep running and consume resources (we'd like them to be killed instead). I did not find an elegant workaround for these issues (but can imagine some non-elegant ones). Anyway, judging from this JIRA issue and from what I read in various discussions, Jenkins is probably just not the right tool for my use-case, which is absolutely fine. I need to investigate different tools or, alternatively, create own custom UI on top of Jenkins REST API, and implement all the limitations/specifics that we need there. Users would use the custom UI, instead of messing with the generic Jenkins UI.
            Hide
            knymer Kim Nyhjem added a comment -

            Artem, thanks for the reference, but the prevention of stopping jobs would only be applicable for some jobs, whereas it is important to have other jobs stoppable by the users themselves. This would require that we introduced a new naming convention, and did parsing on the jobname in the STOP command as well, not a very elegant or maintainable solution.

            I maintain that it should be a security option alongside start build.

            On clean ups, you might be able to set some flag or semaphore at the start of jobs, and poll for flags with no associated job? Good luck on doing your own UI. That is unfortunately out of scope for us.

            Show
            knymer Kim Nyhjem added a comment - Artem, thanks for the reference, but the prevention of stopping jobs would only be applicable for some jobs, whereas it is important to have other jobs stoppable by the users themselves. This would require that we introduced a new naming convention, and did parsing on the jobname in the STOP command as well, not a very elegant or maintainable solution. I maintain that it should be a security option alongside start build. On clean ups, you might be able to set some flag or semaphore at the start of jobs, and poll for flags with no associated job? Good luck on doing your own UI. That is unfortunately out of scope for us.
            Hide
            triangle Shubham Sharma added a comment -

            Hi,

            I am using Jenkins 1.620.
            I have a job that could be build by multiple users.I want to give cancel permissions to only few users(admin) but in case of both Role strategy plugin and Project based Matrix plugin when I check build permissions to user in check box, cancel permissions are granted by default.I want to give selective cancel permissions.

            As per my understanding cancel check box was given to allow a user to cancel build jobs (may be their own or others) but currently any user who has build job permissions can cancel anyone's running job.
            It should be in a way that a user who has cancel permissions can only cancel jobs triggered by them unless he/she is the admin.
            One should not be able to cancel build triggered by other's.

            Correct me if I am wrong.

            Show
            triangle Shubham Sharma added a comment - Hi, I am using Jenkins 1.620. I have a job that could be build by multiple users.I want to give cancel permissions to only few users(admin) but in case of both Role strategy plugin and Project based Matrix plugin when I check build permissions to user in check box, cancel permissions are granted by default.I want to give selective cancel permissions. As per my understanding cancel check box was given to allow a user to cancel build jobs (may be their own or others) but currently any user who has build job permissions can cancel anyone's running job. It should be in a way that a user who has cancel permissions can only cancel jobs triggered by them unless he/she is the admin. One should not be able to cancel build triggered by other's. Correct me if I am wrong.
            Hide
            walterk82 Walter Kacynski added a comment -

            The only current work around would be to delegate build authority to a parent job that calls/triggers the downstream job. You would then only grant the cancel permission to the downstream job to your select group of users. Build users would not have direct Build permission to the job performing your required processing.

            Show
            walterk82 Walter Kacynski added a comment - The only current work around would be to delegate build authority to a parent job that calls/triggers the downstream job. You would then only grant the cancel permission to the downstream job to your select group of users. Build users would not have direct Build permission to the job performing your required processing.
            Hide
            roman80 Roman80 added a comment -

            What is the current status of this issue?

            I think it is in general a good idea that the user which triggers a build could cancel his own job but are not allowed to cancel jobs from other users expect the user has the "cancel" flag or is an admin

            Show
            roman80 Roman80 added a comment - What is the current status of this issue? I think it is in general a good idea that the user which triggers a build could cancel his own job but are not allowed to cancel jobs from other users expect the user has the "cancel" flag or is an admin
            Hide
            roman80 Roman80 added a comment -

            Any progress?

            Show
            roman80 Roman80 added a comment - Any progress?
            Hide
            rui_monteiro Rui Monteiro added a comment -

            Hi,
            Any good workaround for this? I just want to deny cancel permissions to some specific jobs.
            Thanks!

            Show
            rui_monteiro Rui Monteiro added a comment - Hi, Any good workaround for this? I just want to deny cancel permissions to some specific jobs. Thanks!
            Hide
            ndesjardins Nicolas Desjardins added a comment - - edited

            As a workaround, I run Jenkins behind nginx and have it return 401 (unauthorized) for all /stop requests:

            location ~ "/stop$"

            { return 401; }

            You could put your job names in there to have it block the stop request for only certain jobs.

            Show
            ndesjardins Nicolas Desjardins added a comment - - edited As a workaround, I run Jenkins behind nginx and have it return 401 (unauthorized) for all /stop requests: location ~ "/stop$" { return 401; } You could put your job names in there to have it block the stop request for only certain jobs.
            Hide
            roman80 Roman80 added a comment -

            And without nginx

            Show
            roman80 Roman80 added a comment - And without nginx
            Hide
            nify Nico Falk added a comment -

            Hi,
            I have many builds using ClearCase Plugin.
            If the job gets canceled during SCM access, my ClearCase View is irreparably damaged.
            Thus, in this particular case it would be quite handy to remove the "Cancel" permission independent of the "Build" permission!
            Thanks a lot.

            Show
            nify Nico Falk added a comment - Hi, I have many builds using ClearCase Plugin. If the job gets canceled during SCM access, my ClearCase View is irreparably damaged. Thus, in this particular case it would be quite handy to remove the "Cancel" permission independent of the "Build" permission! Thanks a lot.
            Hide
            abhishek_shinde Abhishek Shinde added a comment -

            Any update on this issue ?..

            I have same requirement of grant cancel access to limited folks and build access to all authenticated users..

            I have configured role strategy plugin. Please fix this issue where we are able to configure build and cancel permission to limited folks..

             

             

             

            Show
            abhishek_shinde Abhishek Shinde added a comment - Any update on this issue ?.. I have same requirement of grant cancel access to limited folks and build access to all authenticated users.. I have configured role strategy plugin. Please fix this issue where we are able to configure build and cancel permission to limited folks..      
            Hide
            deenbandhu_agrawal deenbandhu agrawal added a comment -

            Any updates i also need this feature

            Show
            deenbandhu_agrawal deenbandhu agrawal added a comment - Any updates i also need this feature
            Hide
            nfalco Nikolas Falco added a comment -

            me too, our users stops pipeline builds also if they do not have rights too.

            Show
            nfalco Nikolas Falco added a comment - me too, our users stops pipeline builds also if they do not have rights too.
            Hide
            hangsu Hangsu Ma added a comment -

            Hi All,

            I have updated my PR for the fix here: https://github.com/jenkinsci/jenkins/pull/882

             

            Show
            hangsu Hangsu Ma added a comment - Hi All, I have updated my PR for the fix here: https://github.com/jenkinsci/jenkins/pull/882  
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Hangsu Ma
            Path:
            core/src/main/java/hudson/model/Item.java
            http://jenkins-ci.org/commit/jenkins/081e400a5b618b035fa9c350e3bf4341d66e2476
            Log:
            [FIXED JENKINS-14713] make Cancel independent from Build permission (#882)

            A script in the confluence page below will make sure configuration is
            compatible after this change:
            https://wiki.jenkins-ci.org/x/fAAhB

            *NOTE:* This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/

            Functionality will be removed from GitHub.com on January 31st, 2019.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Hangsu Ma Path: core/src/main/java/hudson/model/Item.java http://jenkins-ci.org/commit/jenkins/081e400a5b618b035fa9c350e3bf4341d66e2476 Log: [FIXED JENKINS-14713] make Cancel independent from Build permission (#882) A script in the confluence page below will make sure configuration is compatible after this change: https://wiki.jenkins-ci.org/x/fAAhB * NOTE: * This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ Functionality will be removed from GitHub.com on January 31st, 2019.
            Hide
            danielbeck Daniel Beck added a comment -

            Fixed in 2.120

            Show
            danielbeck Daniel Beck added a comment - Fixed in 2.120
            Hide
            mcrooney mcrooney added a comment -

            Awesome, thanks Daniel Beck! This would be a great LTS backport candidate IMHO

            Show
            mcrooney mcrooney added a comment - Awesome, thanks Daniel Beck ! This would be a great LTS backport candidate IMHO
            Hide
            danielbeck Daniel Beck added a comment -

            The 2.107.x line has ended, the next LTS release, barring major problems, will be 2.121.1.

            Show
            danielbeck Daniel Beck added a comment - The 2.107.x line has ended, the next LTS release, barring major problems, will be 2.121.1.

              People

              • Assignee:
                Unassigned
                Reporter:
                drautureau drautureau
              • Votes:
                31 Vote for this issue
                Watchers:
                34 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: