Authorization System, Access Rights

Discussion created by Mark_Hadler_430 on Mar 11, 2016
Latest reply on May 26, 2016 by laura_albrecht_automic

Currently we have three clients used for production bound objects that application developers have only read access to.  The object developers in these clients, the group I work in, rigorously follow standards of usage so have not needed anything but the most basic folder type security.

We are investigating the creation of a client for shared use by application developers.  We wish to segregate the various development groups based upon the object’s name.  We currently prefix all objects with a two character “system code”; i.e. xx_SOME_OBJECT_NAME, and they exist in a like named folder structure.  The developers would have full access to create, modify and execute objects within their system’s folders.

We are at a loss of how to create a viable and secure client where one group of developers cannot execute or affect another group’s objects.  Folder security has a huge hole with regards to the following documented method of operation:

 Nevertheless, specifying folder rights does not prevent access to objects stored in them. A user who is not allowed to access a particular folder could still access an object in this folder (such as if it is used in a workflow. The command "Edit" is available from almost anywhere, therefore, also in workflows).

Using individual Object Authorization via its Properties is very precise but its method of implementation does not appear to be in any way applicable to our desired requirements.

Our basic desire is to ensure that developers can only affect objects in specific folders and restrict the name of any new or renamed object to match the system code of the Folder in which it is being created.

I was wondering how others do this or something similar as I feel that I'm overlooking something very basic.  Thank you for any assistance or insight that you can provide.