Edit your own ticket according to the ticket status

[nickbe]

You should be able to edit your own ticket as long as you can also theoretically change the ticket status. Otherwise you should only be able to post comments.

So I would simply tie the option to edit a ticket to the users right for changing a ticket's status.

[nickbe]

We thought this thru now and it seems the best way to solve this would be another role limit field per tag.
"Limit Edit". (Important: this should then only be available in status tags).

The rest is again pretty straigt forward.

I could then allow the user role to edit issues while the status is "New" (which would be the default status in my system for new issues) by setting the limit of this tag to "User" and then set all other edit limits to at least developer. But I can also prevent for example developers from editing ticket while I discuss (status: Discuss) them among managers.

This solution would also be consistent with the current concept.

[nickbe]

This seem to work so far. Trying to edit a protected issue shows:

No no no, not this page.
Server Error: 401 (Unauthorized)

I think it would be better to disable the edit button/function completely on readonly and show a small 'lock' icon instead.

[nickbe]

If you look at the develop test instance - there an issue "This is Jims little issue".

• Now if you're logged in as Jim than you cannot edit the issue, despite the fact that the tag NEW does NOT make the issue READONLY.
• Also if you're logged in as Chief Andy you're a manager and therefore see all assigned users. (Not as anonymous, but always with theit correlt name) - The admin user "Master Colin" already dies that but then admin should be manager + special rights.

[satrun77]

I'm not clear about what you mean by the last comment :)

[satrun77]

The latest code in develop branch should allow users to edit their issue if the current tag is not read only. (I have not tested it)

[nickbe]

Did you make the changes just now? I couldn't male this work yesterday

[satrun77]

I just pushed the changes to github.

[nickbe]

Okay thanks. I'll check this out

[nickbe]

In the test system the user "Jenna" just created the issue "Jenna wrote this issue to see if she's still able to edit it afterwards". Neither tag should prevent her from editing but I receive an error when I try to edit the issue.

[nickbe]

User: Client Jane
Issue: "The software does not work on mondays"
Status tag NEW - has a limit access role of USER, same with type tag ISSUE, yet Client Jane who created the issue cannot edit the issue although the status does not seem to forbid this.

[satrun77]

fix deployed to develop. You will need to run composer update.

[nickbe]

Updating just now....
Strange... I still get the same error:
Server Error: 401 (Unauthorized)

I replaced all files from the develop branch,
I ran composer update --with-dependencies

[nickbe]

I tried to update again. But still I get the error.

[satrun77]

I have deployed another fix. This area will need to be planned better. I think your suggestion in #132 might be in the right direction just need more info and planning.

[nickbe]

Now I can edit the issue as "Client Jane", and also when I login as "Operator Sean" and set the status to **IN PROGRESS* the user Jane cannot edit the issue anymore.

But then when the issue has the type NEW and the user jane changes the issue type from ISSUE to ENHANCEMENT then the status NEW is lost. The issue ends up with no current status.

Also Jane is not able to add/edit comments although she created this issue.

[satrun77]

I have pushed a fix for the tag reset issue.

[satrun77]

User role is only an observer in the issue and project. This change add extra ability that the creator of the issue can edit the issue with limited options.

User role cannot add comments or upload attachments.

Roles permissions:

• Admin: can do everything
• Manager: can edit everything in all projects.
• Developer: can edit issues in projects they belongs to.
• User: an observers (new change allowing them to edit issue they have created).

[nickbe]

They're now able to edit their own issue according to the status, right? I think it's only logical that they can comment on that issue no matter if the status locks the issue itself.

I always saw the comments as a type of chat where developers and users (bug reporters) are able to talk about an issue at hand.

1. So in a public project all users should probably be able to comment issues in the projects they're assigned to.
2. In an internal project - users should only be able to comment their own issues (which they've created).

In a private project.... well what? How exactly is a private project defined?

[satrun77]

These changes related to role and permission i would prefer if we talk about it in all aspects and put one requirement for them. This to be done in another issue outside this one. Possibility as part of the new design as it is going to be a new major release v3.

This is because the original Roles & Permissions are simples (comments above). Adding the extra features with tags and allowing user to edit made thing harder to code.

I want to plan all this to make it easier to manager.

[nickbe]

Agreed. you're quite right. We should write down exactly what each role is allowed to do in which situation. I suggest a new github issue for that and to close this one now :D
(See #133)

btw. the lost tag issue is resolved now :)