Announcing the General Availability of Extended Project Administrator

[#1]

Hello Atlassian Community!

We are excited to announce the General Availability (GA) of the Extended Project Administrator (EPA) feature in Jira. This new capability is designed to empower project admins and trusted end users by providing more flexible company managed projects (CMP) management options and reducing the administrative burden on Jira Admins.

What's New?

With this release, we have introduced two new permissions to the CMP permission scheme:

1. Manage Issue Layouts: This permission allows users to edit issue layouts within their company-managed projects, where the screens underlying the issue layout are isolated. Users can now add existing global fields to their project’s issue layouts, enhancing customization without needing Jira Admin intervention.

2. Edit Workflows: This permission enables users to modify existing isolated workflows, such as changing statuses and transitions, within their company-managed projects. This empowers teams to directly manage and customize their workflows.
   
   

   

Learn more about using Extended Project Administrator

Benefits of the Extended Project Administrator Feature

• Increased Efficiency: By delegating these permissions, project admins and skilled users can make necessary changes without waiting for Jira admins, reducing bottlenecks and improving project management efficiency.

• Enhanced Customization: Teams can tailor their project settings to better fit their needs, leading to more effective project management and execution.

• Controlled Delegation: Jira admins retain control over who receives these permissions, ensuring that only trusted users can make significant changes.

Request for Feedback

Your feedback is invaluable in helping us refine and enhance our offerings. Please share your thoughts and experiences with the Extended Project Administrator feature via our support teams.

Thank you for being a part of our journey to make Jira more adaptable and user-friendly. We look forward to seeing how this new feature transforms your project administration experience!

Kind regards,
The Atlassian Team

[Melanie Rusch]

When will this be released? And what will be the default setting? Thank you!

Edit: Nevermind. Found it in the sandbox and the setting is empty.

[Raffaele D’Elia]

Yay, having more flexibility is always appreciated! When a Project Admin modifies an isolated workflow, is that tracked in an audit log?

[Aditi Dalal]

Hi @Raffaele D’Elia glad to hear you are finding this additional flexibility to be helpful! Yes, just as with other workflow activity, changes that are made by project admins (or even non-admins) with this permission, it will be tracked in the audit log :)

[Ricardo Cereceres]

Is this only available for Jira Cloud? Or is it an alternative to extended permissions in Jira Data Center?

[Shawn Stevens]

Regarding these permissions. We currently are going through a consolidation where we are making all projects follow the same structure and setup. Same workflows, screens, permissions, and layouts. 

I know not very flexible, but where we came from we needed some consistency. 

I wouldn't want to enable this for our use case at the moment. Just wanted to confirm!

[James Rickards (Spark-Nel)]

Brilliant.

[Aditi Dalal]

Hey @Ricardo Cereceres this functionality is only available for Jira Cloud at the moment - as you mentioned, Jira Data Center has very functionality also known as extended project administration.

[Aditi Dalal]

@Shawn Stevens confirming that these new permissions will not be enabled by default, so they should not interfere with your standardisation plans :)

[Ignacio Pulgar]

@Aditi Dalal thanks for sharing this!

I love the fact that end users won't be able to create new statuses, unlike with the "Software Simplified Workflow".

This makes it almost directly usable; my only concern is users would need to know one thing:

1. All transitions to a final status should be provided with a Resolution value.
2. All transitions from a final status to a non-final one should clear the Resolution value.
   This implies all global transitions to a non-final status should clear the Resolution, since they can potentially be used from a final status. This is a bit counterintuitive for end users at first.

As Jira Admins, we would need this information to be provided by the tool to the end users through help dialogs. Or, even better, if the users are forced to set statuses as either final ones or non-final ones, the logic above could be automatically set by the solution (set Done resolution or clear it).

If we had this help in place, we won't have any problems providing this permission to end users.

Otherwise, the delegation of workflow edition wouldn't be effectively worth it, since discovering and retroactively fixing wrongly [un]set Resolution values and the poorly-configured workflow takes significantly more effort than the Jira admins directly editing the workflow well.

Let's remember that some gadgets and filters may be impacted by a bad management of the Resolutions.

I have not tested the experience of editing the workflow through the new permission, with an end user account, so sorry if the Resolution topic were already somehow solved. I just thought it would be unlikely that the solution also solved this need if the docs didn't mention anything about it.

Thanks for reading!

[Michiel Schuijer]

100% agree with @Ignacio Pulgar up there.

The biggest blocker for me to allow this type of delegation is the issue with resolution (not) being set.

I already tried the previous setting for this back on Jira DC, and we saw a rise in issues missing a resolution while in the done status category and the same, but less, for re-opened issues with a resolution set. Over time this will cause pollution and give wrong reporting.

I'm all for providing options to delegate, but these issues need to be addressed head-on, first.

For similar reasons, I find team-managed projects unworkable/unhandy. It just creates a mess and extra work for Jira admins, in the long run anyway.

[Yatish Madhav]

Thanks a ton for this @Aditi Dalal , Atlassian and the comments, team!

I am on a similar page as @Shawn Stevens - we have historically used manage shared schemes, incl screen and workflow schemes. With many project admins wanting more control - this is great like @Raffaele D_Elia  stated. And we all know, as admins giving proj admins more control, auditing is more and more key

I saw one of our permission schemes and it looks like currently - the default is to assign to "atlassian-addons-project-access" - is that right? Think @Melanie Rusch 

Aditi - i noticed on https://support.atlassian.com/jira-cloud-administration/docs/permissions-for-company-managed-projects/#Manage-Issue-Layouts  - in the purple info box, it states "...and will be able unable to access any other settings..." - funny typo or is it meant to create confusion hehe - please fix when possible?

Thanks again, Atlassian!

[James Rickards (Spark-Nel)]

I 100% agree with @Ignacio Pulgar

As a simple workaround I would suggest a global automation for Company Managed Projects that watches for a change to a "green" status without the resolution being set, and an email to the owner of the project so they can fix their mistake.  "Trust but Monitor and educate" being my philosophy.

You can tweak the automation to exclude specific projects or issue types if the action is agreed as desirable.

This would directly increase automation usage, which costs Atlassian for Enterprise customers where this is more likely to be an issue, and thus provides financial motivation for them to alter the product to reduce the need for such workarounds.

[JOSL]

Is there anything in pipeline for this role reg. managing versions?

[Aditi Dalal]

@JOSL that's definitely something we're looking at! You can follow the progress of this feature request here: https://jira.atlassian.com/browse/JSWCLOUD-17608