I’m working with the Jira SOAP API in my C# application and running into permission issues. I discovered that the CustomFields() method requires administrator privileges to work properly. There’s also getFieldsForEdit() but that only works when you already have a specific issue key.
The problem is that most regular users don’t have admin access and they might not always have an issue key available. I’m wondering if there are other methods or workarounds to fetch custom field information through the SOAP interface without needing elevated permissions.
Has anyone found alternative approaches for getting custom field data in Jira using C# and SOAP calls? Any suggestions would be really helpful.
I hit this same problem six months ago building a reporting tool. Here’s what worked: use getIssuesFromJqlSearch() with a broad JQL query to grab issues that have the custom fields you want. Then pull the custom field metadata straight from those issue objects. No admin privileges needed since you’re just querying issues you can already see. Downside? You need at least one issue with those fields populated, but that’s rarely an issue. You can also try combining it with getFields() - sometimes that returns custom field definitions depending on your Jira setup and permissions.
have u tried using getCustomFields() on specific issues? it kinda works for me without needing admin access. you can get the data as long as u have read permissions on those issues.
Here’s another workaround that’s worked for me: Use getProjectsNoSchemes() followed by getIssueTypesForProject() to grab the basic project structure. Then hit getIssueById() or getIssue() on any issue you can access in those projects. The issue objects you get back have custom field data in their customFieldValues array - that gives you both field IDs and current values. You can pull the field metadata from there without needing admin permissions. Works great when you’re mapping custom fields across multiple projects since you’re basically reverse-engineering field definitions from real issue data instead of trying to hit the field configuration directly.