ACL for HR Case

[Jon23]

We are currently implementing HR Service Management and have a requirement where an assignment group can restrict case access to their assignment group only.

I have achieved this by adding a new field on the form 'Restrict Case Access' and a new read ACL rule:

Everything appears to work as expected, however, my question is, should I be using 'hr_Factory.getSecurityManager(current, gs).canRead()' as many of the other HR ACL rules appear to be using - after reading the wiki I am confused on how to work with these custom wrappers.

Am i creating issue for myself by not using the wrappers?

[Jon23]

Hi Brian,

I have not got back to looking into this issue based on the advice here - hopefully soon

[jppasala]

Hi Brian,

Can you provide more detail? For example, say you are opening HR Cases to HR workers and external auditor. I am assuming you modified the appropriate code to make the case available to the external auditor. What are the symptoms?

- Are these other users not seeing the record?

- Or are these other users not seeing certain fields?

- Are these other users not able to modify certain fields?

- Can you turn on the "Debug Security" and see the messages as to why the record is not being displayed or modified?

Thanks,
JP

[Brian O_Donnell]

Thanks for following up.

I have a very similar structure in place to what you and jwalton spoke about above.   The last piece that I am struggling with is that the requirement for reading cases is only those that are assigned to a team that you are a member of.

I added this to my custom class that extends hr_CaseSecurityManager:

restrictQuery: function() {

   if (this._gs.hasRole(hr.ROLE_ADMIN)

   || this._gs.hasRole(hr.ROLE_HR_CASE_READER)

   || this._gs.hasRole(hr.ROLE_HR_APPROVER_USER)

   || this._gs.hasRole(hr.ROLE_HR_DISPATCHER)

   || this._gs.hasRole(hr.ROLE_HR_AGENT)) {

           this._logDebug("[restrictQuery] User is a case reader, not adding any conditions");

           return;

   } else {



           this._gr.addEncodedQuery("assignment_groupDYNAMICd6435e965f510100a9ad2572f2b47744"); //dynamic query for "One of My Groups"



           this._logDebug('[restrictQuery] --> ' + this._gr.getEncodedQuery());

 }

},

Outside of the HR Help Desk Agents (hr_case_writer), the other case workers have the hr_basic role so that they cannot read all cases.

When I have Security Debug on, the only record that I see this execute for is the one record that does appear in the list view for hr_case.   When I go to the task level, it tells me that there are 20 removed because of security constraints (which I would expect).   The only record that appears for this user account is the one that was opened by the user - the write and create ACLs seem to work as I expect.   It is only the read that is giving me the problem.   I don't see anything at the sm_order table that should be preventing the read either.

I wasn't sure where to look since the security debugging isn't giving me a lot of information.

[jppasala]

Hi Brian,

Can I restate your problem as follows:

- After using your new script (ie. addition to the security manager), the original user who filed the case cannot see his/her own case.

If this is the issue, then the simple solution is to modify the script on line 11. Make sure the encoded query not only has the assignment group but also the user who created it.

To be honest, if I were implementing it, I would not add an encoded query to the record, instead run a query to verify if the user is part of the assignment group or not. If part of the assignment group, then return true. If not, then make the call to the base class to let it decide whether the user should be permitted to view or not (Why? Because in future versions of HR, SNOW will add new roles and you will inherit the functionality).

Thanks

JP

[Brian O_Donnell]

Just to close this out, I opened a case with HI to get it resolved.   The problem I had was a "feature" that was fixed in Fuji patch 5 (may have been fixed in 3, but we are at 5 now).   There was a protected/read-only before query business rule on the sm_order table that was interfering with my logic.   Once that was disabled, it worked as expected.   Thanks to everyone that offered help in this thread!   It was very useful.