1. Summary
It wouldn’t be too hard to add that with a 3rd party plugin. You could set an event hook to run through the comments, and add it to the top comment.
For bonus points, you could use an LLM to summarise. Every company loves a bit of AI these days, so your manager can gloat with his manager buddies that you now have AI-powered issue tracking.
2. That sounds like an anti-pattern to me. There shouldn’t be PII in your dev issue tracking system.
There problem here isn’t RBAC, it’s the workflow. If you’re in a situation where you need to make notes of sensitive information then you should store that in the same data store as the source information (eg Salesforce, et al). And I say this as someone who hates Salesforce.
3. I’ve not seen this feature in any issue tracker. Sounds like a nice feature but I wouldn’t have thought it as essential.
> That sounds like an anti-pattern to me. There shouldn’t be PII in your dev issue tracking system.
Then how do you track such issues? I'll give you a real example I've experienced: a high-value customer writes to support and complains that his UI is broken. None of the other people's UIs are broken. Do you not use the issue tracking system just because you need to get that customer's private settings and PII in order to debug the bug?
It's common to require PII to be stored elsewhere, but people will still make mistakes and copy paste PII for convenience. In the end isn't it better for your issue tracking system to be flexible enough to store PII?
You can say user ID is broken and define how it’s broken. You don’t have include any of their PII outside of the user ID.
> It's common to require PII to be stored elsewhere, but people will still make mistakes and copy paste PII for convenience.
That’s a training problem.
And It’s also common for people to fuck up RBAC. The latter is a harder problem to fix with training than teaching them to keep PII out of issue tracking systems.
> In the end isn't it better for your issue tracking system to be flexible enough to store PII?
I’ve worked in some very sensitive domains. They managed just fine keeping customer data out of the issue tracking systems.
The user ID is a piece of email. It is PII. To define how it's broken is to describe a list of specific actions the user did to the private information in their account causing the UI to be broken.
If training is such a problem, I don't understand why we solve the problem by obviating such training and make the issue tracking system an acceptable storage medium for PII?
Because you were the one that said you needed granular RBAC to limit who has visibility of what issues!
3. ServiceNow incident tracking has something close called “work notes”. Work notes are for internal team members with a certain role, where comments are public and meant to communicate to the issue reporter.