Request for Read-Only Access to Configuration Metadata

[steve_yang]

Dear Team,

I hope this message finds you well.

I would like to respectfully ask for your understanding and reconsideration regarding the current access restrictions on configuration metadata.

At the moment, even read-only access to the following configuration items is blocked and results in a 401 response:

• Workflow metadata

• Screen configuration

• Project role definitions

I fully understand and agree with the need to restrict update or modification capabilities for these sensitive configurations. That level of control is absolutely appropriate.

However, I am struggling to understand the rationale behind blocking read-only access as well.
Being able to view these settings is essential for analysis, troubleshooting, documentation, and ensuring alignment across projects—especially when no changes are being made.

Without visibility into the current configuration state, it becomes extremely difficult to:

• Diagnose issues accurately

• Validate setup consistency

• Provide reliable operational support

• Avoid unnecessary back-and-forth requests

I would like to emphasize that this request is not about expanding privileges, but simply about enabling transparency through safe, read-only access.

If there are specific security or governance concerns behind this restriction, I would sincerely appreciate your guidance so that we can find an acceptable and compliant alternative together.

Thank you very much for your time and consideration.
I truly appreciate your support and look forward to your advice.

Kind regards,
Steve

[steve_yang]

Thank you for taking the time to respond. I appreciate your perspective.

However, I believe there may be a misunderstanding regarding the nature of my original question, so I would like to clarify it briefly.

My inquiry was not about:

• How to use specific REST API endpoints

• Troubleshooting incorrect API requests

• Missing or undocumented API behavior

• Requesting a product change or raising a feature request

I fully understand how to call the relevant REST APIs and which endpoints return 401 responses. That part is clear and intentional.

What I was asking is fundamentally different.

My question is about the design and governance rationale behind the current access model—specifically:

Why is read-only access to configuration data (such as workflows, screens, and project roles) entirely blocked, even when no update or modification capability is requested?

I am not suggesting that these configurations should be modifiable. Restricting updates makes perfect sense.
What I am trying to understand is why visibility itself is restricted, and what operational, security, or governance considerations led to that decision.

This is a policy and design question rather than a technical “how-to” or API debugging issue.

Understanding this rationale is important from an operational standpoint, as visibility into configuration state is often required for analysis, support, documentation, and alignment—without changing anything.

I hope this clarifies my intent.
Thank you again for your time and for engaging in the discussion.

Kind regards,
Steve

[Sunny Ape]

Sorry, but I have absolutely no idea what "access model" you are talking about.

Since you haven't provided any information whatsoever about HOW or WHERE or WITH WHAT you are 'accessing' what you are calling 'configuration data' related to workflows, screens and project roles, nor provided any links to any documentation that describes this 'access model' thing or HOW or WHERE or WITH WHAT you got Jira to produce a "401 response" or how or why you think you are being, "blocked", nor even at the very least provided any screen grabs that show WHERE and HOW any of this is happening, then I simply am not able to decrypt what you are talking about.

Perhaps you are using something like Google Translate or an AI to convert your question from your native language into English, hence the reason why it is so vague and non-specific and uses so many broadly abstract words. If that is the case, perhaps you might be best to post your question in your native language and maybe someone on the forum who can read it will be able to better understand what you are talking about.

Alternatively, use Google to search on the broad topics of how to read or modify any of the data inside Jira using the REST APIs, the Java APIs, or even directly accessing the internal database. There are literally thousands of articles, documents and discussions on these topics.

Anyhow, I can be of no further assistance to you. Good luck with whatever it is that you are trying to accomplish.

[Sunny Ape]

Hello @steve_yang 

It's a little difficult to understand exactly what you are talking about, but I'm guessing when you use words like 'Configuration Metadata' and 'configuration items' that you're talking about objects or things in your company's Jira Data Center instance and their settings / configuration / values, and when you say "At the moment, even read-only access to the following configuration items is blocked and results in a 401 response:" you are actually talking about retrieving the settings / configuration / values of those objects or things using the REST API. Is that correct?

If so, you need to actually provide such meaningful information as:

1. Which specific REST API endpoints are you sending requests to that are generating those 401 errors.
2. What are the actual requests you are sending to those endpoints and what are you sending them with.
3. What settings / configuration / values were you expecting to get back from those endpoints that is not bring provided as described in the REST API documentation.

With that information, someone might be able to provide some sort of advice on the matter.

In closing, generally speaking, using this public forum to ask someone, somewhere to somehow do something or other about how Jira Data Center works is not going to actually result in anything of consequence. If you really want to change the product 's behaviour, you need to raise a Feature Request for that and, to be blunt, raising feature requests for a product that Atlassian have publicly stated is coming to the end of its life and development is essentially winding down, is a mostly pointless exercise.... even more so considering you are using an outdated version of that product.

IMHO, your best course of action is to work within the constraints of the product as it currently is.