Accept plugin not showing up if user is not neither in Project Administrator nor Developer role

[giwlak]

Hello,

The Accept button only shows up if user is in one of the following roles assigned to the project:

• Administrator
• Developer No matter if issue is assigned to the user which is in mentioned roles or not assigned to any user (this is good as then we can assign "approval" privileges to role not only user), the accept is visible. The only case when the button is not visible is when user is not in any of mentioned roles. Even if we assign issue to the user with different (custom) role, which we currently use as "Approvers" role, the button is not visible for any user.

[stefanzugal]

Hi,

I am sorry, I do not really understand your issue: is this a bug you have experienced or a feature request?

[giwlak]

Hello,

Both.

The bug is that only redmine built-in roles members can see the button. If assignee is from custom role (created by administrator, like in my case I have Approvers) then nobody from this role can see the button, even if person from Approvers role is picked as assignee to the issue.

Features

1. The button should be visible not only by assignee but also for the whole role which has rights to "approve" the issue according to the defined workflow.
2. It would be good to define also roles in plugin options page (next to statuses) which are able to approve according to workflow. Sometimes there's a group of persons which should be able to approve the Issue to be solved (like for example Management Board members).

[stefanzugal]

Let's focus on the bug first. We are also using custom roles in addition to the built-in roles, so that should not be a restriction. Could you please check for the following snippet in the redmine page where you the accept button is missing (it is usually easiest to find by searching for the string "acceptTicket")?

<script>
var isStatusPresent = $("#issue_status_id>option[value=2]").length > 0;
var isAssigneePresent = $("#issue_assigned_to_id>option[value=7]").length > 0;
var isNotAccepted = $("#issue_status_id").val() != 2;

if (isStatusPresent && isAssigneePresent && isNotAccepted) {
 var button = $("<a class=\"icon icon-accept\" onclick=\"acceptTicket()\">Accept</a>");
 $("#content .contextual:first").append(button);
}

function acceptTicket() {
 $("#issue_status_id").val("2");
 $("#issue_assigned_to_id").val(7);
 $("#update input[type=submit]").click();
 } 
</script>

The script checks the necessary preconditions for accepting (status is available, assignee is available in the list to choose from, and the issue is not accepted yet). Are these preconditions satisfied in your case?

[giwlak]

Hello,

OK. Situation like follows:

1. My user is project member in role "Approvers".
2. Issue is waiting for approval, noone is responsible.

3. Accept button is not visible (from my point of view should be!). Script snipped looks like follows: ``

2nd approach:

1. My user is project member in role "Approvers".
2. Issue is waiting for approval, I am responsible.

3. Accept button not visible. Script snipped looks like follows: ``

3rd approach:

1. My user is project member in role "Developer".
2. Issue is waiting for approval, no one is responsible.

3. Accept button visible. Script snipped looks like follows: ``

My workflow of issue for custom Approvers role is as follows (sorry for Polish).

[stefanzugal]

Hi,

thank you very much for the detailed explanations! The snippet is available - this is good. Now it would be interesting to know why the button does not show up, this depends on the following conditions (in your first example):

var isStatusPresent = $("#issue_status_id>option[value=3]").length > 0;
var isAssigneePresent = $("#issue_assigned_to_id>option[value=49]").length > 0;
var isNotAccepted = $("#issue_status_id").val() != 3;

Could you please load the page, open the developer tools in your browser, paste these conditions and let me know the output? To make the button visible, all three conditions must be satisfied.

[giwlak]

Hi,

Below screens. Only isAssigneePresent variable is read wrongly. Rest two of them are on "True". 1.When logged in as Admin - status below.

2. When I am Developer/Project Administrator and Approver in Project - status below.

3. When I am only Approver and / or assigned in Project - status below.

[stefanzugal]

Hi,

thank you very much for the detailed answer. It seems that the user with id 49 is not listed in the "Assignee" selection and hence cannot be selected by the accept plugin (or perhaps the css selectors is wrong).

Could you please search for the html fragment where the currently available users are listed? It should look like this:

<select name="issue[assigned_to_id]" id="issue_assigned_to_id">
    <option value="">&nbsp;</option>
    <option value="7">&lt;&lt; ich &gt;&gt;</option>
    <option value="59">Alexander</option>
    <option value="44">Andreas</option>
    <option value="54">Benjamin</option>
    <option value="13">Bernd</option>
    <option value="53" selected="selected">Jens</option>
    <option value="7">Stefan</option>
    [... some more options here]
</select>

Does it contain an user with id 49 in your case? If yes, can you see why the selector "#issue_assigned_to_id>option[value=49]" does not match?

[stefanzugal]

Hi,

was your user is listed in "Assingees" (see comment above?)

[giwlak]

Hi!

When I am logged in as "approver" then I do not see above select field in both screens: read-mode and edit-mode (this is read-only field for this user as he can only approve - not to assign responsible). In our workflow we have developer or reporter creating an issue, then approver which approves the change to be done. Afterwards such change is "ready to be picked" by developers. Therefore developers are picking up the issue depending on their availability or internal discussions. Also project administrator can assign responsible person manually.

When I am logged in as project administrator this is what I see yet in read-mode (after entering the issue number before clicking the Edit button):

[stefanzugal]

Hi,

if I understand you correctly, the approver in your workflow will never assign issues to himself, but rather approve/decline issues (in other words: an approver will never be the "Assignee" of an issue).

If this is correct, this plugin will not work in this case, because it is intended for a different purpose: it will always change the "Status" field and the "Assignee" field at the same time. If one of the fields is not available, the button for accepting will not show up. This is because the plugin mimics the "accept" button from Trac, which does exactly that: setting the status to "Accepted" and setting the the "Assignee" to my acount.

[giwlak]

Hello,

When I changed permissions to "Assegnee" field, the approve button is visible. As you mentioned - this is needed for the plugin to work. Thank you!

Can we focus on features then? Allow me to recall them:

• The button should be visible not only by assignee but also for the whole role which has rights to "approve" the issue according to the defined workflow

• It would be good to define also roles in plugin options page (next to statuses) which are able to approve according to workflow. Sometimes there's a group of persons which should be able to approve the Issue to be solved (like for example Management Board members).

• NEW: Assignment behaviour of the plugin should be configurable so that not always "Approve" = "assign me to the issue". In our case it is just "green light" from management to make the change happen.

[stefanzugal]

I think we have a problem of misunderstanding here. The one and only purpose of this plugin is to do the following things at the same time (as also described in the readme of this project):

• set the Assignee to "me"
• change the status field to a pre-defined field (mostly "accepted", but this can be configured in the settings)

That's it - this is the only, minimalistic purpose of this plugin. From what I can see is that points 1 und 2 are already working (assuming the logic of changing assignee and status at the same time) and point 3 is against the basic idea of this plugin.

Perhaps the name "accept plugin" might be misleading in your case, because your workflow has stages with similar names. Since this an open source project, feel free to fork and adjust to according to your own purposes - I would like to keep this plugin as minimalistic as possible.

[stefanzugal]

No response so far - I think I will close this one.