JIRA Workflow-based permissions plugin

Added by Jeff Turner, last edited by Jeff Turner on Jun 07, 2006  (view change) show comment

JIRA Workflow-based permissions plugin

Name JIRA Workflow-based Permissions plugin
Author(s) Atlassian
Home Page  
Download Location http://repository.atlassian.com/atlassian-jira-workflowbasedpermissions-plugin/
Plugin Version
JIRA Version
Comments
1.0 3.0 - 3.2.x

1.0.1 3.3.x
Updated constructor for compatibility with JIRA 3.3
1.0.2 3.5.x
Removed dependencies from constructor and called statically (was causing Cyclic Dependencies)
1.0.3 3.6.x
broken and deprecated. Reports indicate that this plugin breaks subtask editing. Another user reported it breaking issue creation in 3.6. More seriously, even if this plugin worked it will break certain bulk operations like Bulk Move, which do not expect permissions to vary by workflow step. See JRA-6381 for further discussion.

Description/Features

This plugin replaces some core JIRA classes responsible for permissions checking, with versions that check the value of 'properties' set in the current issue's workflow. This allows you to alter permissions by issue state. For example, you might not want an 'Approved' issue to be editable or assignable to anyone except project managers, but to be editable/assignable in other states.

This plugin is essentially a hack. We are aware that the need exists for this type of fine-grained permissioning, and a more elegant solution than this will one day be written. Please add your votes/thoughts to JRA-6381

Assigners

Workflow step property Example value
jiraext.issue.assigners ${pkey}-managers

The "Assign" link will be visible if the user is a member of this group (where '${pkey}' will be replaced at runtime by the current project's key). If this meta attribute isn't present, the usual permission scheme-based checking is done. If the meta attribute is present, there is no "fallback" to the permission scheme checks – the user must be present in the jira.isssue.assigners group.

Assignable users

Workflow step property Example value
jiraext.issue.assignables ${pkey}-developers

This property filters the drop-down list of possible assignees for an issue. First the regular "Assignable" check is done, and then the results filtered for membership of the 'jiraext.issue.assignables' group. If jiraext.issue.assignables isn't specified for a step, all permission-derived users are returned.

This property can be set on the workflow step. With a code modification this can be made to work on transitions too.

Limiting operations

Workflow step property Example value
jiraext.issue.linkable true/false
jiraext.issue.editable true/false

If set to false, issues won't be editable/linkable in this workflow step. Otherwise, standard permissions apply.

Limiting operations on subtasks

Workflow step property Example value
jiraext.issue.subtasks-editable true/false
jiraext.issue.subtasks-deletable true/false
jiraext.issue.subtasks-assignable true/false

Labels

 

Comments (6)

 

  1. Mar 16, 2006

    Venus says:

    there is a bug i found of this plugin. when i add the plugin in my 3.5.2 enterpr...

    there is a bug i found of this plugin.

    when i add the plugin in my 3.5.2 enterprise version

    all the sub-task don't have the "edit" option.

    1. Mar 19, 2006

      Nick Menere says:

      Hi Venus, Thanks for reporting. Are you able to raise this bug on our JIRA inst...

      Hi Venus,

      Thanks for reporting. Are you able to raise this bug on our JIRA instance.
      Officially we do not support these extensions but we will see what we can do (depending on what is required to fix it).

      Cheers,
      Nick

  2. Apr 04, 2006

    Bettina Zucker says:

    Hello, if I try to disable this plugin or one of its modules, I get an error and...

    Hello,

    if I try to disable this plugin or one of its modules, I get an error and my Jira crashes. I have to restart it.
    I have Jira standalone enterprise 3.5.1.

    I just wanted to disable the plugin so I can edit my sub-tasks and then enable it again, as a workaround
    for the bug found by Venus, but the effect was worse than the bug itself.

    Cheers

    Bettina 

    1. Apr 05, 2006

      Brian Nguyen says:

      Hi Bettina, This problem may not be related to the plugin, and may be caused by ...

      Hi Bettina,

      This problem may not be related to the plugin, and may be caused by Jira. So is it possible for you to create an issue at http://support.atlassian.com with a explanation of the problem?

      Also, probably a better solution would be to remove the references to the plugin itself. So for example

      1. Copy the existing workflow
      2. Remove the parameters from the transitions
      3. Associate the new workflow to the project
      4. Edit the sub tasks
      5. Reassociate the project back to the old workflow
        This obviously will take longer to achieve but would ensure that you don't disable a feature that is currently in use.

      Thanks,
      Brian

  3. Jul 05, 2006

    Michael Richey says:

    To fix issue creation after installing this hack, we modified the first getUsers...

    To fix issue creation after installing this hack, we modified the first getUsers method in WorkflowBasedPermissionSchemeManager.java:

         public Collection getUsers(Long permissionId, PermissionContext ctx)
        {
            GenericValue projectOrIssue = null;
            if (ctx.getIssue().getGenericValue() == null )

    Unknown macro: {                projectOrIssue = ctx.getProject();        }

            else
    Unknown macro: {                projectOrIssue = ctx.getIssue().getGenericValue();        }

            return getUsers(permissionId,projectOrIssue);
        }

    Now it won't throw the null pointer exception anymore and both workflow based permissions and issue creation seem to be working for us.

    1. Jul 05, 2006

      Michael Richey says:

      Delete the "Unknown macro:" stings from the above code....the rich text editor m...

      Delete the "Unknown macro:" stings from the above code....the rich text editor must have thrown them in there...