[Spaz]

Hi everyone,

I have recommended to our recruiting dpt to have a look at CATS in an effort to stop (ab)using excel spreadsheets.
Some time later they came back to me with one (major) question. User access rights.

We want to use CATS internally and we want to have the system provide info to the users (some of them in production dpts)
on a "need to know" basis. Example: Production dpt A must fill in a job order. They must be able to "see" only "their" job orders.
And they should be able to review the status of candidates assigned only to their job order pipeline.

They came back with a whole bunch of questions / features. If any dev is interested i could post some. The one i mentioned
is a show-stopper that's why it goes first.

Thanks

[RussH]

I've attached a screenshot of the options available when creating a user - which doesn't answer your particular question but does show the general access levels.

However - by default all the levels have rights to see all open job orders. There is however a checkbox on the joborder page to show 'only your joborders'. You'd need to ensure this option is hardcoded if you wanted to restrict viewing of others joborders. You may have to make some similar changes elsewhere in the app - but they're all relatively minor.

[Spaz]

Hi RussH,

I appreciate the immediate response. Things around here got hectic and that delays things . I did some search in the
forum and I think i got to start putting some pressure on the my IT folks.

Thanks

[johnvanja]

I would like the ability for the administrator to create accounts called "Recruiters", and each recruiter will have their own candidates and their own job orders and will not be able to see other recruiters information. I have a company with several recruiters and it's best that each recruiter manages their own world of job orders and candidates and do not need to share in one large pool like the way it works now.

Does anyone have any suggestions for that?

Thanks

[RussH]

Hiya,

if you log in as 'recruiter1' and go to your candidates tab, you can check the box on the page to say 'show only my candidates'. There's a similar checkbox on contacts, job orders, etc,etc - so the recruiters can work entirely within their 'own' workflow. The checkbox status is saved across logons (from memory)

[opencatsusr]

Hi, have the user access level features above been rolled out in the latest version of OpenCATS? If a recruiter logs in, does he only see his own jobs, candidates, companies etc.? Is he able to view other recruiters' contacts/jobs? Thanks.

[RussH]

HI,

yes the ACL features are fully deployed and you can set user roles which have fully customisable permissions i.e. user xxx has a role of recruiter, user yyy has a role of resourcer, and user zzz has a role of manager, then you can choose what each of the individual roles has access to.

[opencatsusr]

Thank you!

If I assign multiple people with the role "recruiter" - say Recruiter 1, Recruiter 2, etc., would the jobs, candidates, clients, notes etc. added by Recruiter 1 ONLY be visible to Recruiter 1?

Same with the other roles - meaning, each user is in his own silo, and never sees the data of the other users, except the Admin.

[RussH]

Morning! Have asked the author of the ACL system to reply to this thread for you.

[skrchnavy]

Hello.

Unfortunately, your requirement is not addressed in ACL implementation.
This is overview, how it works and how it shall be configured: https://github.com/opencats/OpenCATS/wi ... trol-Lists

Implemented ACL is extension of access level (permissions) in OpenCATS. Standard access levels allow to add user to a level with READ, EDIT, DELETE or ADMIN (higher level includes also lower level).

ACL just extended this to define role with access level per specific object (or feature of openCATS).
* Role 'R1' is created for 'candidates' (secured object) with access level EDIT
* User 'U1' is created with a default permission level (for example DELETE). And is assigned to be in role 'R1'
Result is, that user 'R1' has access level EDIT to all features with exception to candidate feature (and sub-features) where user has access level DELETE.
It could be setup oposite way, user can have default access level DELETE and for example job order feature could be disabled to setup 'jobOrder'=>DISABLED.

Feature to protect instances in DB (candidates, joborders, pipelines) is not implemented.

Best regards.
Sveto.