git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JIRA Workflow Proposals


It looks like we have a multiplicity of views on permissions, so perhaps we should complicate this particular vote with all of the possible options that have been raised so far (including one off-list).  Sorry everyone for the confusion.

(A) Only contributors may edit or transition issues; (B) Only contributors may transition issues; (C) Only Jira-users may transition issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as they are today

* Today apparently ‘Anyone’ can perform this operation

A ranked vote, please.  This makes my votes:

1: A B C D E
2: B C A
3: A
4: +0.5


> On 11 Dec 2018, at 05:51, Dinesh Joshi <dinesh.joshi@xxxxxxxxx.INVALID> wrote:
> 
> I agree with this. I generally am on the side of freedom and responsibility. Limiting edits to certain fields turns people off. Something I want to very much avoid if we can. 
> 
> Dinesh
> 
>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <murukesh.mohanan@xxxxxxxxx> wrote:
>> 
>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>> <benedict@xxxxxxxxxx> wrote:
>>> 
>>>> On 10 Dec 2018, at 16:21, Ariel Weisberg <ariel@xxxxxxxxxxx> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> RE #1, does this mean if you submit a ticket and you are not a contributor you can't modify any of the fields including description or adding/removing attachments?
>>> 
>>> Attachment operations have their own permissions, like comments.  Description would be prohibited though.  I don’t see this as a major problem, really; it is generally much more useful to add comments.  If we particularly want to make a subset of fields editable there is a workaround, though I’m not sure anybody would have the patience to implement it:  https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html <https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html>
>>> 
>> 
>> That would be disappointing. Descriptions with broken or no formatting
>> aren't rare (say, command output without code formatting). And every
>> now and then the description might need to be updated. For example, in
>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
>> paper had rotted, but I managed to find a new one, so I could edit it
>> in. If such a change had to be posted as a comment, it might easily
>> get lost in some of the more active issues.
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx