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; } } }

How do you stop users changing work item types via Move or Bulk Move?

Aqib Ilyas

Jira's workflow validators only act on workflow transitions. But a work item's type can change through paths that never run a transition: inline edit of the Type field, Move Issue, Bulk Move, and subtask conversion. So a validator you set up carefully on a transition does nothing when someone bulk-moves 40 Stories into Task.

How are you all handling this? Permission scheme tweaks, automation rules, admin training, or just accepting it?

For context, I could not find a clean native way to block it, so I built a small free app called WorkType Guardrails. An admin defines which type changes are not allowed per project (a From type and a To type), and it blocks them across all four of those paths. It runs on Atlassian with no external data, and stores only the work type IDs in a project property inside your own site.

Genuinely interested in how others approach the governance side, and whether I am missing a native option.

Comments

__ Jimi Wikman

Considering you can never be sure that the work item in space A is the same as in space B, anything you set up that tries to force this will break sooner or later.

This is why you have no function like this, as you would need to build system checks that only allow a move if the work item is identical in both the target and the origin.

This is where trust in the users that you give permission to bulk edit comes into play. The need to move work items is also a destructive function, so it should hopefully not be needed often, making this a rare occasion and one that should not be difficult to handle by the receiving team in the target space.

May I ask why you need to maintain the same work item in a move?

Maria Reisinger _MetaFrazo_

Jimi, one answer to your question from the governance side, though Aqib may have his own: in many setups the work type decides which workflow applies, and with it which controls. A Change that becomes a Task can skip an approval step entirely, without anyone breaking a rule on purpose. So even if blocking every path isn't realistic, it is worth knowing afterwards when a type changed outside a transition, by whom and in which project. If moves are as rare as you say, that review is cheap. Does anyone here check this on a schedule, or only when something breaks?

Sami Shaik

@Aqib Ilyas , the four paths you list are not four holes; they are two permissions, and both are already yours to restrict. Validators were never the tool for this, because a type change is not a workflow event.

1. Move Issues (project permission) governs three of the four. Changing the type inline, the Move wizard, and converting a subtask to a standard type (or back) all require the Move Issues permission in the project's permission scheme (permissions overview). In most default schemes that permission sits with "Any logged-in user" or the Member role, which is why the paths feel open. Move it to a role you control (Project Administrators, or a dedicated "Triage" role) and the inline Type field becomes read-only for everyone else, the Move menu item disappears, and subtask conversion is refused. That is the durable fix for the single-item paths.

2. Make bulk changes (global permission) governs the fourth. Bulk Move is a bulk operation, and bulk operations require the Make bulk changes global permission (global permissions), on top of Move Issues in every target project. Take that global permission away from the general groups and give it to a small admin group, and forty Stories cannot become Tasks in one click by anyone outside it. This one change also stops most of the other bulk accidents that get reported as "someone changed everything."

3. Narrow what a move can become. Move can only target types in the destination project's issue type scheme. If Task is not in the scheme, nothing moves into Task. Where a type only exists for one team, put it in a separate scheme rather than the site-wide default, and the wizard simply will not offer it.

4. Detect what slips through. For the people who legitimately hold Move Issues, an automation rule on Work item type changed (the Field value changed trigger with the Type field) can log the change, notify the project lead, or, for the pairs you never allow, move the item back to the previous value with {{fieldChange.fromString}}. Note this costs steps under the metering that starts in December, so keep the trigger scoped to the projects that need it, and be careful with reverting, because Move can also change project and keys.

On the governance question you asked: I do the first two everywhere, the third where a type is team-specific, and the fourth only in the two or three projects where a wrong move has a real cost. Training does not hold; permissions do.

Welcome!

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

Quick Links

Find more posts tagged with

atlassian-marketplace

jira

jira-administration

app

permission