A number of wishes have been submitted in TCP concerning adding rights to an objects.
They indicate that when rights are granted to an object, they must also be granted to its childs. Same goes for revoking these rights. I was able to extract the following situations:
- Rights for a table should pass on to its columns
- Rights for a task should pass on to its task parameters
- Rights for a report should pass on to its report parameters
- Rights for a menu should pass on to its menu items
- Rights for a process flow should pass on to its process actions
A number of questions about this wish:
- What if a new column / task parameter / report parameter / menu item is added after setting up the rights?
- If you give a table rights because you need a column look-up, you now only get the display. Should this change?
- Am I still missing situations that should also be taken into account for this wish?
- Personally, I think that when adding a table task, for example, it is going too far to give rights to both the table with its columns and the task with its parameters.
Since you have reported a wish concerning this topic, I would certainly like to hear your opinion. Other opinions are also of course appreciated.
I’m wondering - what was the reason for the wish, I only see a solution - but not the problem that has to be solved.
Why not follow something like filesystems do - explicit permissions overrule inheritance (as in no explicit permission equals the parent permission)
The question that remains in this is - who may be a parent? Can a (table)task be the parent of a table?
I think new columns/task parameters should behave based on a setting of the parent. So base this on a property like 'auto_assign_new_column’. I think the default value when granting a complete table should be ‘yes’. When you are being granular at first setting this up, it should be ‘no'.
All the votes have been transferred into this idea.
It would be nice if the rights structure in TSF is visible everywhere within the context of objects (tables, tasks, reports, columns, parameters, etc).
Just like translations are available everywhere.
In regards to setting up the rights, I indeed would prefer when I set through the tasks that Tasks, Reports or Tabdetails, Tabtasks and Tabreports should also be set to granted, all of these tasks, report and tables their parameters/columns should also be made granted and available.
Because currently the SF will allow you to set these objects to granted and available through the task and in the table, task and report list the will show up has read only. However since no column or parameters has been assigned the rights have not been set at all. So this is giving a false pretension.
So if be default these parameters and columns are also set to granted (editable) if you enable these tables, tasks and reports through this tasks, that will save a lot of headaches.
In regards to managing rights on exists roles, I agree with RJ his idea. You should be able to mark tables, tasks, reports, etc.. as auto assign new rights. This auto assign new rights should also be included as a parameter in the task to assign rights. Otherwise after setting rights you would still have to manually walk through all objects again to set this checkbox.
All the votes have been transferred into this idea.
I like Ricky’s suggestion in that columns always inherit the rights of the table unless explicitly defined otherwise. This is quite similar to column rights in SF. A table can have an editable column in its data model. This column is then also editable in the GUI definition under subjects unless it’s overruled there in its list, form or both. I think I would like this style best in rights as well.
All the votes have been transferred into this idea.