nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Set Feature, Story, Sub-task as ReadOnly When Portfolio Epic Moved to Next Status?

Digvijay Singh Gehlot_fgm3gu

Hi Community,

I have 4 level hierarchy : Portfolio Epic > Feature > Task > Subtask in a project.

My use-case is:

When Portfolio Epic moves from In Progrss to Close status, then all it's linked children should be set as ReadOnly irrespective to Child's status.

For example:

EPIC-1000 has it's child as FEATURE-2000

> FEATURE-2000 has it's child as TASK-3000

> TASK-3000 has it's Subtask as SUB-4000

If EPIC-1000 moves from In Progress to Closed status, then all it's Children (Features), Grand Children (Tasks) and Great Grand Children (Subtasks) should be set as ReadOnly irrespective to Child's status.

Please assist for the above if it is possible via Jira Automation Rule, scriptrunner behviors, jmwe app, etc.

Thanks

Accepted answers

Trudy P Claspill

Hello @Digvijay Singh Gehlot

What problem are you trying to solve by making the descendant issues read-only?

What would you expect to happen if the Portfolio Epic status changed again to something other than Closed?

Is it a requirement that this be accomplished without changing the status of the descendant issues?

If not, then one option would be to add a status (i.e. named Read-only) to the workflow of each of those item types. Set the Properties for that status so that the issues become read-only. Create Automation rules to address moving the descendant items to that new status when the Portfolio Epic transitions.

All comments

Trudy P Claspill

Hello @Digvijay Singh Gehlot

What problem are you trying to solve by making the descendant issues read-only?

What would you expect to happen if the Portfolio Epic status changed again to something other than Closed?

Is it a requirement that this be accomplished without changing the status of the descendant issues?

Digvijay Singh Gehlot_fgm3gu

Hi @Trudy P Claspill ,

What problem are you trying to solve by making the descendant issues read-only?

Our customer's business case is,

Once Portfolio Epic moves to Closed status, then all it's linked Children (Feature), Grand Children (Task), and Great Grand Children (Subtask) should be set in ReadOnly - so that Task users should not allow to edit any task details when Epic is in Closed.

What would you expect to happen if the Portfolio Epic status changed again to something other than Closed?

All linked children should be editable when Portfolio Epic moves to any other status except Closed.

Is it a requirement that this be accomplished without changing the status of the descendant issues?

Yes, it is a typical use-case where user is allowed to move the Portfolio Epic to Closed, although, it's linked children are not moved to Closed i.e. Portfolio Epic can move to Closed, without checking the Child status and then all the children linked via hierarchy will be set as ReadOnly automatically.

However, it would be great if you could share the steps/ screenshots on how to configure a Jira Rule for hierarchy item types by adding a ReadOnly status, I will try it out at my end and see if it works for our customer.

Thanks

Trudy P Claspill

Thank you for that additional information.

I'm still trying to understand the problem being solved. You've told us the solution that has been requested, but I'm still not clear on why this solution is needed.

What problem is being solved by allowing the Epic to be set to Closed when the work to complete the Epic (the descendant items) has not been completed?

I'm drilling into this to try to ensure the best solution is implemented.

I'm not aware of a way natively to set individual issues to Read-only regardless of their own status and based on the status of another issue, with only native Jira functionality. The solution that comes to mind would be, as I mentioned, changing the status of all those issues to a new value where the Properties of the Status can be used to set it to Read-only.

There might be another solution possible with third party apps, but I don't have such a solution readily available in my portfolio. And currently I don't have the bandwidth to research such a solution.

Before investing the time in explaining the details of a Read-only Status solution, though, I would like to ensure that solution will truly address the underlying problem that needs to be solved.

Digvijay Singh Gehlot_fgm3gu

Hi @Trudy P Claspill ,

Just to keep it simple, I wanted to check if we can set the linked children (as per Portfolio hierarchy) as Read Only when Portfolio Epic moved to a specific status.

Your suggestion worked from me and fulfilled the customer's requirement.

I configured as blow:

Add Read Only status and apply Property: jira.issue.editable to specific user group on Feature, Task, Subtask workflows.
Create 3 jira automation rule and enable "Check to allow other rule actions to trigger this rule" in Feature, Task, Subtask rule details.
a) Rule A: Trigger: Work item transitioned to Closed > Condition: Issue Type = Portfolio Epic > Branch: Children > Condition: Feature > Action: Transition to Read Only
a) Rule B: Trigger: Work item transitioned to Read Only > Condition: Issue type = Feature > Branch: Children > Condition: Task > Action: Transition to Read Only
c) Rule C: Trigger: Work item transitioned to Read Only > Condition: Issue Type = Task > Branch: Subtask > Action: Transition to Read Only

In Rule B & C, enable "Check to allow other rule actions to trigger this rule" in Rule Details.

Please kindly let me know how we can refine the above rules further as it will be a great learning for me.

Thanks

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

scriptrunner

jira

cloud

adaptavist

jira-cloud

hierarchy

advanced-roadmaps

status

appfire

parent

child

parent-link

app-central

behavior