Nic Brough -Adaptavist- Expert

So the boards I'm working with all use "resolution date", not "updated". I'd question why people are using things that bulk-clear or bulk-change the resolution when they don't need to.

Attachments follow the restrictions of their containing page, so no, you can't do this directly. What you might do is use the attachments macro to show your files on one page (unrestricted), but point it to pull the attachment list from another page which is more limited, so they can't change them.

Actually, please do not. I've spent a lot of time working with people who have non-standard vision (of course, that mostly those who have a lower range of vision than most of us for some reason). One of our own big names in Atlassian (as is "a long time customer who has presented at Summit") is colour-blind. Most of us…

the limitation is that you can't track them, so it makes the use of an issue tracker pretty pointless.

The issues are in a status that is mapped into a column other than the very last right hand one on the board.

From 7.1, in theory, you could go to 8.6 direct, but I would recommend 7.13 before 8.6. Atlassian will give you standard support - each problem you have, you'll need to raise a support request and wait for a response. If you want something a bit more dynamic, contact a partner - most of us help with or even completely do…

If it is in the backlog, then it is not "done" - for Scrum boards, that is "in the right hand column of the board".

Um, look at it and work with it?

I'm afraid the only answer we can give is "read the server log" - that will have more detail on the "something went wrong" part.

I'd also point out that the workflow you've given us is not the "normal jira workflow", it's one that has been created by one of your admins already (probably starting from a copy)

Licences are not related to projects. Each licence seat allows one person to be active on the service. Sharing an account means you can't track people's activity and technically breaches your licence agreement.

The "program" was misconfigured. A program is (probably) a set of projects, not one. In fact, I'd argue you're missing several more layers (although Jira does not do them natively and you'll need Portfolio or similar apps for smaller programs and Align for bigger ones) If you want Jira Software to behave correctly, then…

Yes, I've currently got two projects running away from Monday.com because of the mess made by multiple assignee. Thank you for the evidence.

Next-gen boards belong to their projects. You will need to use classic boards with board filters like "project in (x, y, z)" to get data from many projects.

I would remove "move issue" in your service desk projects, and educate your agents to use "create linked issue" - a linked issue can update the original, without removing the whole thing from customer view.

Not really "advice" here, in my opinion, more an explanation of the underlying data and a criticism of what Atlassian have done! And, of course, total agreement on "Strange". Bug - I'd say that too. The search, the data, meh, but definitely a bug if you leave sub-tasks hanging. Great that we have "add parent", but that's…

Slash commands are fantastic. I ran into them <mumble> years ago when writing on operating systems that died years ago despite being more advanced than Windows 10, and have appreciated them ever since. Especially when I landed in a place that essentially developed, supported, and improved one of the biggest web sites in…

We will need some more information on this request. On the surface, it seems wrong, as "done" means "done", so you don't really want them on a board. But I think there's a more complex process we don't know about. Could you explain?

I've been digging too, I can't see anything that might help. But given the heavy Agile stuff I've been doing since Christmas, I tend to think this is right. You don't care about the specific status of issues in a backlog.

If you have set the field as required in the right field configuration, then my guess is that you've not managed to connect that field configuration to the project and issue type.

It's not quite a case of "banned", just "unsupported". It will almost certainly continue to work for quite a while. But Atlassian are moving to shrink their support base away from the edge cases. At the time of me scribbling this answer, the edge cases are "Anything but Windows and Linux" - the server world runs on Linux…

You are going to need one of the scripting or automation plugins. If you do go for Scriptrunner, https://library.adaptavist.com/entity/copy-field-value-from-parent-issue-to-sub-task-upon-creation might be a good starting point. It's actually upside-down, but should give you enough of the code you need to invert it.

I can't think of a use for multiple parent pages itself, it just messes up your tree and navigation. However "having the same content under different pages" (not quite the same) does have some uses, and you can do that with "include" macros. For example * Page: Top * Page t1: Child of top 1 * Page t2: Child of top 2 *…

Behaviours are front-end functions, you'd need to write them to work in several different places, REST would ignore them, as would certain automations and other scripts. If you don't want to do it with a post-function, then look next to a "listener" that can catch the event (whatever it is - ideally, a custom "cancel"…

Once someone has shared a filter you find useful, you can also copy it for yourself and save that for your own use.

There is no difference by tier, no. I'm not sure it is actually called out specifically on any particular page, but it is mentioned in many. I do know my 10 user play version is identical to my unlimited clients version.

Ok, there's a couple of tricks here. The sub-tasks are not true orphans. They appear to have lost the link to their parent, because the parent is an Epic, and there is even an "add parent" in the tools menu for them. They don't look like they have a parent, and the parent has disavowed them. But the data for the link is…

There are two classes of changes to an issue if you change its workflow. * The data. Not a huge impact, but the issues cannot have no status. So if your old and new workflows share status, existing issues will not actually change at all. Where an issue is in a status that the new one does not have, you will be asked to…

Do not do this. You will break Jira in some "interesting" ways (fortunately non-destructive, you'll just find a whole load of stuff starts failing for no apparent reason) Use a validator to make the field mandatory on creation, or, if you have Scriptrunner, a Behaviour.

We need to be careful with language here. Jira deliberately does not use "ticket" because it's a bad word (in English) to represent the concepts of what it is really trying to do. So. Jira is an issue tracker. Issues live in projects. Jira users can create issues (ok, permissions can control that, but that's the main…