Nic Brough -Adaptavist- Expert

You deploy Cloud apps to production the same way you deploy them to a test system - via the marketplace. It's all detailed at https://developer.atlassian.com/platform/marketplace/installing-cloud-apps/

>It's funny how you mention that the time logging is configurable but the assignee is not. It feels like all arguments could be applied to both features. Why is the time logging configurable, but the assignee is not? Time logging and responsibility for an issue are two totally different things, with different purposes and…

Yes, if you read an issue (via UI or REST), you'll get the history, where any change of key is recorded.

No, that's not an accurate statement. All the burndown report data is available over REST. Because it is the issue and sprint data. The burndown reports themselves do not have any data, there is nothing to extract or query on. The reports are generated from the issue data, they're simply a view of that issue data, which is…

Sorry, I should have mentioned that in my first response! I keep forgetting it! Glad you got there though.

The rationale is to prevent people getting into a mess with "I thought someone else was doing it". It's an anti-pattern, it's a disaster in most places (in some heavily regulated fields, it's even illegal, with good reason). So, yes, you've found your answer - Jira doesn't do multiple assignees, never will directly, but…

Ok, that's valid version, I think we'll need to look at the log files for errors at the time that the error is shown to a user.

Ah, yes, you need to use their raw username - it won't autocomplete or suggest anything. If, for example, you removed me from our Jira, you would have to type out "assignee = nbrough" in full.

Nope, Jira work logs are added to issues by separate people, irrespective of the assignee. You may have configured yours with permissions that say "only assignee can log work", but that's absolutely not the defualt. Your example fits perfectly into all the stuff discussed above. I'm not going to repeat it again as you…

Search for "assignee = <person who has left> and issue is open" (Generally, you probably don't want to reassign ended issues, it's better for your historical view to leave the gone person on closed stuff). Once you have the list, use "bulk edit" from the issue navigator's option menu, and you'll be able to mass-update the…

See above - you don't measure expenditure by assignees, the most obvious thing to do is measure it by actual work logged (you don't have to be the single point of ownership to log work on something) And for the piano - "I thought the other one was doing it". That is the monumental nightmare that multiple assignee lands you…

Have a close look at your workflow, and where it is setting or clearing the "resolution" field. If the resolution field is empty or null, then an issue is "open". If it has any value in it (fixed, done, cancelled, unresolved, needs work, ended, etc), then the issue is "resolved" and will not appear in the list of "open…

There's no difference between the software when you install open-source-support, academic or commercial Server versions. It is just the licence that matters, and yes, you will need a licence for installation. Atlassian are not licencing new Server installs any more, as the software is going away and they're encouraging new…

The reports are generated on demand from the current issue data. So yes, you can always go fetch the issue data from which they are built over REST.

Yep, but the point there is a well-functioning team won't need to pay much attention to an assignee field. They certainly won't even begin to think they want a multiple-assignee field. Team ownership of issues would be done elsewhere (for example "it's on our board")

Yes, all the way through, I've been saying the same thing - The "permission work denied" property you have there is in the wrong place, it is not a transition property, it goes on a step.

Welcome to the Community! Status and resolution are two totally separate things with different meanings and values. Do not confuse them. * Status is an indicator of where an issue is in its workflow (process step). * Resolution is a field that gives us a broad idea of why someone believes an issue is "resolved" and needs…

I'm a bit stuck on exactly what you are looking for, and I can't think how to try to replicate it. For a working project, could you tell us what type the project is, what type of board it is using, how the swimlanes are configured and how you are creating an issue that automatically lands in the swimlane you select?

What app are you using to provide the transitions custom field? Did you update the app after upgrade?

That's an internal error on the Cloud side, and the code you are getting is not much more than a marker in logs and data for the Cloud support people to see where its happened and to whom (these sort of errors usually affect blocks of Cloud sites, they're not usually limited to a single Cloud user) You should raise this,…

I'd start with a look at exactly how you have defined the swimlanes in the boards that are working right, then compare that with the swimlanes in the boards that are not working. That should tell us something, but if they look the same, then yes, Automation is the next place to look, as it could well be doing "on issue…

You have never been able to create an issue in a column other than the one that contains the first status in the workflow. You can create inside specfic swimlanes, but only when the swimlane has a clear definition Jira knows how to work with. If you set swimlanes to stories for example, then you can create in a swimlane…

>Can this be done? Yes >Who should create this space so that only these teams can have access? Your Confluence administrators >What Governance is required before using this space for restricted data? We can't tell you that, it's your governance you need to check >How long will it take to set up restricted confluence space…

That's what a burndown is supposed to do - you burn down when an issue is complete, not part way through.

It does, yes. The "declaration" is a caveat - it is subject to the Great Firewall And it has been known to get blocked by that sometimes.

No problem, I think the conversation with Aron is the more useful one for getting you a good data set, I just wanted to say numbers are nothing to worry about! One of my old clients had an array of devices to test everything against and their build servers were generating thousands of global versions every day. Jira was…

I know, it does seem like the syntax check should be enough to enable the save button, and for a lot of us, it probably is. But there are enough people in the minority who inadvertently write bad JQL to justify a quick test before saving. (I'm in that minority by the way - I get over-confident about my JQL skills…

The two-dimensional grid can only work with list type fields on its axis, not free-form unlimited data fields. Dates are not list types. There isn't an easy way to "fix" this, you would need to write your own gadget that would be able to treat dates as lists, or possibly write something that could take any date on an issue…

What have you put in the web-panel? A common usage is to put a custom field in them, or a display based on existing fields (almost a "scripted field"). So to "update" your panel, you would write data into the issue fields and the panel would display them or a calculation.

Jira's select list custom fields do have a technical limit on the number of entries, and so do the Insight field (I believe it's the same limit) The actual limit is far higher than the number of entries that the code would start to struggle to handle, which is a lot higher than the number your browser would start to…