The Activity tab in the reference view returned the full step definitions of an approval path, including the data of Webhook steps. As a result, webhook headers (as well as the request URL and body), which may contain internal secrets, tokens, or API keys, were exposed to users who should not have access to them, including external JSM customers.

Other views (approvals list, definitions) already masked this data. The Activity tab is newer and skipped that masking. This change aligns its behavior with the rest of the application: sensitive webhook data is now masked, while all other information needed to display the activity list remains unchanged.

Masking applies to all access levels (administrator, collection view, JSM customer). The activity list never displays these fields anyway, so no user loses any information they need.

Acceptance criteria

1. JSM customer

• Configure a definition with a Webhook step that has headers filled in (e.g. Authorization), available to JSM customers.

• As an external JSM customer, start an approval and open the Activity tab.

• In the activity response/preview, the webhook header, URL, and body values must be masked (they must not contain the original secret).

2. Administrator and collection view

• Open the Activity tab as an admin and in the collection view.

• The activity list renders correctly and completely (names, statuses, dates, steps, initiator, versions) with no errors or missing data.

3. Consistency with other views

• The same webhook data is masked the same way as in the approvals list and the definition view (uniform behavior).

4. No regression in non-sensitive data

• For a Webhook step, the technical data needed for the step status still displays correctly (e.g. HTTP method, status code, step status).

• Steps of other types (user, email, group, automation) work unchanged.

5. Both products

• Verify on both Jira and Confluence (the Activity tab is available in both).