Daniel, thanks for constructive reply despite a bit provocative message.
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.
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.