Hiding certain comments/work notes from specific users

[Community Alums]

Hi everyone,

we have an interesting business requirement that proved quite difficult to implement. We have numerous groups working on our platform and they often collaborate on the same tickets. The catch is that some groups shouldn't see the work notes from certain groups/users. This is due to security reasons.

How I tried to approach this:

• ACLs: the record.work_notes ACL does trigger on each work_note but I cannot get any more context information about it. Therefore, I can either block all of them or none. I need to get the sys_id of the work_note to find the author and then operate from there on. I don't know if ACLs allow you to retrieve that information somehow even if they trigger on each specific work note.
• Data filters are not specific enough to facilitate this. 
• Query BR: the activity stream mechanism is a mystery to me, it contains 4 tables but I am not aware of how they work together (sys_journal_field, sys_audit, history set and also sys_activity). Even if I make a query BR on one of them the BR doesn't trigger when someone opens the activity stream. If I was able to understand the activity stream mechanism a bit better then maybe I could build something around it.

There are probably options to hide them using any of the front-end functionality but I'm reluctant to go this way.

Did anyone ever tackle a similar requirement? I can see other use cases where there is a need to hide toxic/proprietary/secret information from certain users and therefore not show that comment/work_note. I'm sure I'm not the first one who had to hide activity stream records based on some metadata in the actual work note. Any ideas on how I can approach this? Did I miss something in my initial investigation?

[SanjivMeher · Accepted solution]

I think I would create separate child task for each group working on the same tickets. 

And add ACL on child task table to only show worknotes on the child task, if the task is assigned to my group.

Adding ACLs/restrictions to work notes doesnt sound like a good idea.

[Community Alums]

Hi, thank you for the suggestion, it was a good one. I've checked with our users but this is not something they are willing to use as it changes their way of working too much. Do you see any other ways to approach this?

[Dr Atul G- LNG]

 Hi @Community Alums 

Path suggested by @SanjivMeher  is good , and if client is not agree then I think there is no good way to do this. 

[SanjivMeher]

That would be the most recommended way. I wouldn't add any additional script/BR on the OOB tables. The Audit tables, history tables are huge and stores audit related information of all tables. Making changes to it will have negative impact such as performance issues, future maintenance, impact on other modules etc.