Royal Render Help

rrControl job list

It is NOT possible to restrict the minimal job list. This includes the render app, user name and project name.

It is possible to restrict job commands like enable/disable/client assignment/...

It is possible to restrict jobs details like scene name, frames rendered, preview image display, ...

For most confidential projects it is sufficient that users cannot see what is rendered (preview images), but it does not matter if they see that scene shot234_take3 is rendered.  You have to decide how far you need to restrict the access.

RR job data

There are RR job folders in RR/rrJobdata/...

RR creates jpeg images of the "preview" images in rrControl, they are saved there. You can enable "Encode jpeg images" in rrLogin/Rights that nobody can open the images in any other app that rrControl. rrControl can only decode the images if it has access to job details like the scene name.

Render log files are saved in rrJobdata as well. So anyone can open the files in any text editor.
The files include all information that Nuke/Maya/... reports during render.

rrConfig, tab jobs, upper right has a setting to choose the location for the rrJobData folder.

It can be  [RR]\rrJobdata\[project]\[job]\ or  [JobProjectRoot]\rrJobdata\[job]\
[JobProjectRoot] is defined by RRs project recognition, which is usually based on the scene/image folder //fileserver/share/projects/<Projectname>. rrControl, upper left filter "Project" shows the company projects that rrControl has recognized by the settings defined in rrConfig, tab jobs, center column.

Render Wranglers/Admins

If you change settings in rrLogin/Rights for  users, then you can still create special users that have access to all jobs.

rrControl takes the user who currently is logged in in Windows/Linux/macOS by default or you can specify that user have to login in rrControl with a password  (there is an option to remember the user with PW for a user at its workstation)

Note: This does not work if you enable the option "Hide job info in rrControl if OS user cannot list files..." mentioned below.

"Hackers"

Depending on how advanced your artists are, it can be possible that someone writes a script and submits it to RR.

This script can copy any file from any project to an other project.

You can restrict the write-access to the RR/sub/history_db folder for users (not for RR!), then you can still check all jobs that have been submitted and check for script files.

At last, someone can hide a script in a Maya scene file, which is impossible to track if he changes the scene and deletes the script afterwards.

Windows Only:

A solution would be to enable "Multi-user login" in rrConfig, tab rrLogins. 

Then the rrServer and rrClients check for  the project name of the job it handles.

It takes the project from the rrLogin list and uses its "Fileserver Login" settings to connect to the fileserver to access the data.

Note: If it does not find the project, then it tries to access the fileserver without any login. In this case Windows/Linux either uses the user of the process (Which should be User for rrService) OR the last user that was used to connect to that fileserver, which might be the confidential project!
If you have the confidential project on one fileserver and the other projects on a different fileserver, then you should create an dummy share on the confidential fileserver. Then setup all non-confidential projects rrLogins to connect to this dummy share. This way the user for the connection to the confidential fileserver is changed and the rrClient can not access the confidential data any more.

Restrict by submission artist/user

You can change rrLogin "Anonymous" and restrict that only users that have send a job can change/view/.. jobs of their own, but not other jobs.

But this has the disadvantage that if you have multiple Windows user logins working on a project, then they can not change jobs of other others working on the project.

Note: 

If you change the jobs user in the rrSubmitter or in rrControl, then you transfer the job to an other user.

Note: 

rrControl takes the user who currently is logged in in Windows/Linux/macOS by default. 
You can specify that users have to login in rrControl with a password  (there is an option to remember the user with PW).
If you enable a login, then the rrServer verifies that the rrControl is in fact the same user as setup in rrLogins and not a user with the same name.

Note "Anonymous":
It is not required to add a rrLogin for each artist. If the artist does not exist in rrLogins, then the rights of rrLogin Anonymous is used.

In this case the rights for "Own jobs" apply to jobs that have the same user as the user logged in.
Example: Artist "Michael" does not exist in rrLogins. Michael submits a job. Michael starts rrControl. If he wants to change the job he just submitted, rrControl applies right from "Anonymous/Own jobs". If he wants to change other jobs, rrControl applies the rights "Anonymous/Jobs of OTHER user"

Project/Render-App logins

Instead of users, you can create rrLogins based on your render apps (e.g. Maya, Nuke) or company projects.

If you start rrControl, then you still have the rights as mentioned before ("Anonymous" or rrLogin matching your OS user)

But if you want to modify/access jobs that you do not have the right to, you have to change the login in rrControl.
(again, you can remember login settings for each user on each workstation)

Example A: 
Artist "Michael" may or may not exist in rrLogins.
Michael and many other artists work on the project "Superhero-Feature".

Michael starts rrControl.

If he wants to modify jobs he submitted (user "Michael"), then the rights of rrLogin "Michael" apply ( or "Anonymous" if Michale does not exist)

Michael needs to access/modify jobs submitted by a colleague working on "Superhero-Feature".

He changes his login in rrControl to "Superhero-Feature".  Michael can now modify all jobs of project "Superhero-Feature".

Example B: 

You have a compositing render wrangler.

But he is not allowed to modify 3D jobs. Therefore you cannot create a rrLogin for his user and give him access to all jobs.

You create a new rrLogin "Nuke". Your render wrangler changes his login in rrControl to "Nuke".

Project access by file access

There is an option in the lower left of rrLogin/Rights that tells rrControl to check if you have read access to the projects root folder.

(The projects root folder is defined by the project recognition in rrConfig, tab jobs. E.g. //fileserver/share/projects/<Projectname>)

rrControl gets the job list.

Then it tries to list the project root folder. 
If rrControl finds some files/folders, then it displays the job.

Note:

This does not affect scripted access to the rrServer.

But scripted access can not show preview images. 
If you have changed the rrJobData location to your project root, then it is not possible to access render logs as well.