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

Cancel permission is granted for users having build permission

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • core
    • Jenkins 1.465

      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?

          [JENKINS-14713] Cancel permission is granted for users having build permission

          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

          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

          Hangsu Ma added a comment -

          Hangsu Ma added a comment - code change in jenkins can be find here: https://github.com/hangsuma/jenkins/commit/1d0be0016bc498810579d8494c87bbd2922893b3

          Hangsu Ma added a comment -

          Hangsu Ma added a comment - pull request here: https://github.com/jenkinsci/jenkins/pull/882

          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.

          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.

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

          Walter Kacynski added a comment - Kohsuke, can you comment on the original design goal of the build/cancel permission relationship?

          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.

          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.

          Shannon Kerr added a comment -

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

          Shannon Kerr added a comment - Thanks Walter, yes Kohsuke, I would like to understand the original design goal.

          Is there any progress with this issue?

          Nickolay Rumyantsev added a comment - Is there any progress with this issue?

          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.

          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.

          Jon Radon added a comment -

          I would also like to see this fixed.

          Jon Radon added a comment - I would also like to see this fixed.

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

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

          Daniel Beck added a comment -

          dedekind:

          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. jglick 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.

          Daniel Beck added a comment - dedekind : 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. jglick 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.

          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.

          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.

          Daniel Beck added a comment -

          dedekind

          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?

          Daniel Beck added a comment - dedekind 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?

          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.

          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.

          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?

          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?

          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?

          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?

          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.

          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.

          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.

          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.

          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.

          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.

          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.

          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.

          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.

          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.

          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

          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

          Roman80 added a comment -

          Any progress?

          Roman80 added a comment - Any progress?

          Rui Monteiro added a comment -

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

          Rui Monteiro added a comment - Hi, Any good workaround for this? I just want to deny cancel permissions to some specific jobs. Thanks!

          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.

          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.

          Roman80 added a comment -

          And without nginx

          Roman80 added a comment - And without nginx

          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.

          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.

          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..

           

           

           

          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..      

          Any updates i also need this feature

          deenbandhu agrawal added a comment - Any updates i also need this feature

          Nikolas Falco added a comment -

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

          Nikolas Falco added a comment - me too, our users stops pipeline builds also if they do not have rights too.

          Hangsu Ma added a comment -

          Hi All,

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

           

          Hangsu Ma added a comment - Hi All, I have updated my PR for the fix here: https://github.com/jenkinsci/jenkins/pull/882  

          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.

          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.

          Daniel Beck added a comment -

          Fixed in 2.120

          Daniel Beck added a comment - Fixed in 2.120

          mcrooney added a comment -

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

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

          Daniel Beck added a comment -

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

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

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

              Created:
              Updated:
              Resolved: