Note: This concept deviates from the initial question but I figured an answer to the permission based question would provide me the tools for this second category. So we want to store the legacy data in a read-only custom field. That been said, the closest you can get to the functionality you are looking for would be to allow the customers to access JIRA issues, but not be able to edit it. They will need to have access to the issues/tasks to see their information in the reports. And there is at least one field coming from the legacy system that doe not translate well to a native Jira field. That been said, there is no permission level to restrict users only to see reports on JIRA. Examples of such fields include the legacy defect ID from the old defect management system. If you add a field that references an object that is too far removed from the object that youre reporting on, you may not be able to sort by this field. We have fields that are being populated during import which we want to remain untouched for the life of the defect. Two, we are migrating defect handling from a legacy defect tracking system to Jira. We only want the people managing the defect handling process to be able to change the risk profile of an anomaly after it has been created.
We are a medical device company and our products have the potential, like many medical device products, of injuring the patient and/or clinicians. The main examples are the fields that define the risk profile for defects.
One, we want to lockdown fields based on permissions. There are two categories of fields we want to lockdown.
Brough -Adaptavist- I appreciate you taking the time to provide that explanation.
0 kommentar(er)
