I’ve been able to apply displayConditions in the Manifest and restrict the field from populating conditionally through App / Edit functions, but the field values still appear in the Issue History. Is there a way to hide the Forge Custom Field in the History or prevent it from updating the History at all?
Hi David,
The displayConditions in Forge only control the visibility of the UI elements of your app, to provide a clearer or simpler UI experience for example, they are not intended to remove the field altogether.
There is no way to prevent field changes being recorded in the history of an issue - the purpose of the issue history is to provide a log of all the changes made to an issue and its associated fields.
I hope this explains,
Mel
Thank you @mpaisley for the reply! I understand displayConditions are more a convenience feature. I’ve been able to control the values displayed based on the current user in the App and I’ve since realized the Formatter also needs to be set for non-rendered views such as search result columns. It seems the issue history is the last point of concern (please let me know if I’m missing something else).
The goal is to securely keep and display values for a specific field for specific users/groups, without having to store this information in a separate issue. For the moment, I’ve resorted to encoding the value before storage and decoding the value for display, but a cleaner and more robust solution would be appreciated. Do you know if there is a recommended approach (using Forge)?
If there aren’t potential features for securing individual fields, it would be nice if we could set Custom Fields to opt-out of logging in the native history (if we would like, we could potentially log separately in the app storage). Are there any feature requests which we could vote/watch for related to this?
Hi David,
Obviously i’m missing a lot of context for what you’re building, but is there a reason these values need to be stored within an issue field? Could you use Entity Properties for example?
Cheers,
Melissa
Hi! Thank you for the suggestion. As far as I understand, users who have Edit permissions on the Issue would still be able to access the Entity Properties through the API, even if the Forge App is applying restrictions in the normal Issue view. I think this might solve keeping the value out of the Issue History, but it seems we would still need to encode/decode the value (which pretty much breaks searching based on the field – not ideal but better than nothing). Definitely correct me if my understanding is incorrect since I don’t have any actual experience with the Entity Properties and thank you so much for the discussion.
To try to give a little more context with what I’m hoping to do, we have information that we want to be visible and editable by a larger group “A” and then only some fields that would be visible and editable by a smaller group “B”, and were hoping to do this using the Forge Custom Fields / Custom Field Types. For example, an Issue might represent a client project and include a description, start and due dates, etc. that should be generally visible/editable, but would also include certain “secure” fields that would only be visible/editable by a smaller group of higher level users. Things such as project cost, revenue, risk, client contact info, etc.
Hey @DavidPezet1,
Thanks for explaining.
I’m wondering, based on what you’ve just said, if the Forge Storage API might be the better option for you? This data is only accessible to your app and can be queried as well.
It also allows you store sensitive data using storeSecret (though sensitive data cannot be queried).
Cheers!
Mel