Matt Doar_tzgiej Community Champion

For Jira Server, I would investigate this plugin https://marketplace.atlassian.com/apps/1210932/cute-for-jira?hosting=server&tab=overview

Looks good to me. Perhaps add a transition from Denied to Under Review for the cases where someone accidentally denies the request? Do you have the same set of people approving requests for all the different components?

Perhaps the Cloud REST API could be useful?

Well, one behaviour that the users might see is different results in Zephyr reports, depending on which Data Center node they are logged into. Are these just for Zephyr indexes or for Jira indexes as well? I guess rebuilding the Zephyr index on one node offline would give you a reference number to compare other nodes to.…

Glad to help. 

What is your question? Also: Steps to Reproduce, Expected Behaviour, Actual Behaviour will help

Not that I am aware of. You could try one of the Jira sync plugins for low traffic volumes. But I don't know of a way to have one master for read/write and multiple proxies for read

When you create a project, select the the Create with Shared Configuration link at the bottom. Not as obvious as it could be I think. But you can't turn it off

The information about a release that the teams might see is really just the start date and release date. I'm rather surprised that these are treated as confidential information within the same company. I don't know of a way in standard Jira to restrict who can view this information except to track the sensitive release…

Or with Jira Software you can use Epic issues to collect other issues together, often used for a company "project"

What exactly do you mean by a sub-project? Why do you need these sub-projects? There are other ways to select the issues you want. Jira features such as the Components field and custom fields allow you to filter out a subset of issues in a Jira project. 

https://community.atlassian.com/t5/Marketplace-Apps-articles/Atlassian-Community-guidelines-for-Marketplace-vendors-and/ba-p/689723 has some broad guidelines about this

Perhaps see if using the standard workflow for that issue/project makes any difference? Also check the Network tab in the developer tools to see if you can tell which network call fails when you click Complete.

Good solution! 

The key part is that you want to create one ITSS and then configure each project to use that same ITSS. In that ITSS you have a mapping from the issue type X to a screen scheme usually named "X Screen Scheme". That screen scheme then has a mapping to one, two or three screens for creating, editing and viewing issues of…

I'd log a support request on this. I bet they've seen it before

Do the log files have any errors in them? Check the Chrome Inspector console for any JavaScript errors too? https://confluence.atlassian.com/confkb/universal-plugin-manager-inaccessible-or-does-not-show-any-plugins-224402405.html has some ideas you may have seen already

Good idea! With a date in the filename to help keep track of multiple upgrade attempts

Blakes 7. I thought of Avon as a role model. Which seems a bit concerning in hindsight.

I read dictionaries for fun. I read all of the Encyclopedia Britannica during breakfast for a couple of years, before https://en.wikipedia.org/wiki/The_Know-It-All did the same thing And I enjoy Harry Potter too!

Good to know. The doc page linked at the top of this thread could make that clearer I think :)

The actual question was whether jira-admins can view LDAP and AD configuration. I thought that they could not, but jira-system-admins could

Ah, no.

Hmm. Time for an Atlassian Support ticket I think

And you made sure that the Global Permissions only has jira-system-administrators in the JIRA System Administrators area?

I suspect your workflow for that issue is not clearing the resolution when the issue is reopened. Global transitions also have to clear the resolution because they can be the path to a reopened status. Check the History tab of your issue very carefully. Another way this can happen is if someone Moved the issue to a new…

But if they can't change the settings, are you concerned about them being able to view the settings?

Hmm, https://confluence.atlassian.com/adminjiraserver072/managing-global-permissions-828787760.html?_ga=2.221609496.1210289335.1529944497-541760740.1525713204#Managingglobalpermissions-sysadminAboutJIRASystemAdministratorsandJIRAAdministrators just says that jira-administrators cannot configure LDAP, not whether they can…

How much text did you paste in? Did it have any unusual characters?

Short answer: no