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!