Nic Brough -Adaptavist- Expert

Yes, those are the two tables I was thinking of (15 years and I still haven't quite memorised the database table names)

If you are just rebuilding from the UI, then no. However, if you are (as in the article) you are dropping out to the command line and removing files, then yes, as Confluence will hold some of the index files open so you can't delete them and it'll lose references to them. You need to restart to allow it to create the new…

Resolution is not, and has never been "mandatory" in the same way other fields are done in the field configurations. It does kind of behave like it is though. It's purely a technical difference, not something that I'd really bother most people with. Consider all the other select type list fields - they're a list of options…

That answers it - your LDAP server is failing to respond in time.

The order you see issues in is determined by any "order" clause you use in your filter, or if you don't put one in, it'll be the issue key. There is no "order by the order I entered things into an "in ()" statement in the filter"

Yes, that's right. Some people have tried to build "locking" into their flow (Atlassian have no plans to do anything about this, as when they've analysed large systems to see how often it happens, it's surprisingly rare), but there are a couple of easier tricks. One I've done is to disallow assignee changes directly, but…

What do you mean by "within out virtual disk surrounding"?

You know, I completely missed the "sub-task" part of the question while I was trying to work out what else might be the problem, I'm sorry! I would replace def linkedIssues = ComponentAccessor.issueLinkManager.getInwardLinks(issue.id).findAll { it.destinationObject.issueType.name == linkedIssueType } with def linkedIssues…

I think you need to re-read that statement more carefully. It does not mention the screens at all. It is talking about when a field is edited. Or could you explain the behaviour Jonathan is seeing? Or what I see when I set a field as mandatory and leave it off the create screen? (I.e. "Field x is mandatory" and no creation)

Not quite clobbered. The first person to save changes would have saved what they had updated. The second person's changes will indeed override anything different, but it will all be tracked in the history. (I'd also question why people are "working on it for an entire day" - issue tracking is something you dip into, not…

Simple approach would be to use the "created vs resolved" chart, maybe with a filter like "issuetype in subtaskissuetypes() and sprint in opensprints()"

The only option in plain Jira for this is to use a cascading select list field. If you have one of the scripting apps, you might be able to get a bit closer (I'm only familiar with the Behaviours module in Scriptrunner, as I work for Adaptavist, I don't have a reason to look at other apps)

The 2-dimensional gadget can only use "bounded" fields for its axes. That means fields that have a known list of values, not the possibility of effectively infinite single values. Text and number fields (including story points) could have any number of values, so it can't use them.

I'm afraid that is not true. This is why Jonathan is having this problem - the field is mandatory but not on the create screen. The system is demanding the field be filled, but it can't be because it is not on the screen, so you can't create it.

Go to the page and "attach" the file to it. Be aware that Confluence has size limits, and is not intended as a file store. You may struggle if it is a large file.

Add the bug outside the sprint, put it into the backlog.

I didn't really "get" it either, until I came to understand Scrum properly. A sub-task absolutely should behave as it does in Jira. It is part of a Story (issue) and it's really nonsense for it to be treated as anything other than that part of a story. And if a story is in a sprint, it's nonsense to have parts of itself in…

They might not be being selected by the rules you have set for what to synchronise or by permissions on the LDAP side. I'm afraid without any errors on the Jira side, you'll need to debug what LDAP is doing. You could increase logging on the Jira side to see if you can get more detail from the connection it is trying to…

That means your network is not set up correctly. It is blocking Confluence trying to reach the database server or possibly its own address or even just the server's networking subsystem. You should have more error message telling you what it is trying to reach and what the problem is.

I think you may have put the "post function as cleared or none" in the wrong place. That post-function needs to be used on every transition out of "done" type status (i.e. the ones that should be in the "closed" status category and in the last column on boards)

I apologise for seeming to be dismissive, I did not intend to, but I know I often over-shorten what I'm saying. It is, as you say, not a great implementation because people don't get it straight away. I would say it is correct in the sense that you should not allow delete generally and you should have to deliberately…

You'll need to read the log file to find out if this is a problem with the sync. And check that the user does actually exist in LDAP as you expect it to.

The basic "create sub-task" as a one-off can be taken from https://library.adaptavist.com/entity/create-a-sub-task-and-link-to-parent-issue-in-jira - you'll want to embed the "create" in the a loop read from the "# of sub-tasks needed" For the estimate, from memory, you can use<span> setOriginalEstimate</span> ( <number of…

I think I saw something about "allow select lists to be chosen", but I don't know if it's on a roadmap

Jira has a rather blunt "mandatory field" system and for historical reasons, tends to rely on apps for cases where fields have more complex needs. The Jira system is just "a field is mandatory or optional". This runs throughout the lifecycle of an issue, the status, other fields, who the person is - all irrelevant.…

Edit access to attached files is down to whether a person can attach a (new copy of) a file or not. The space permissions allow you to say who can or cannot attach files, so you'll need to check that. I'm afraid it does not go down to a page level unless you are willing to get apps that add new functions for more file…

No, you must use a single base url for Confluence, you can't have more than one. If it's server, then yes, you can fiddle with it a bit to deactivate the message, but I wouldn't bother. Using Confluence on a secondary url fails a lot, as it will always eventually take you back to the base url. You will need to change your…

There are some options for apps to add panels into the Jira issue view, but you are going to run into problems with duplication. The panel you are looking at is a system generated panel, it is coded deep in the heart of Jira. When using the issue view, this panel grabs all the date/time type fields and groups them into…

If you are behind a proxy, you can enable logging of the urls hit and you'll see that preview and "open" are different.

Yes, that's correct, if a person has permission to see something, they can see it. If they do not have the permission to see it, then they can't see it. You need to restructure your pages so that the pages you want to share are in a space visible to contractors (and included in internal spaces if they need to be duplicated…