I’m wondering - what was the reason for the wish, I only see a solution - but not the problem that has to be solved.
- What if a new column / task parameter / report parameter is added after setting up the rights?
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'.
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.
The following idea has been merged into this idea:
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.
The following idea has been merged into this idea:
All the votes have been transferred into this idea.
The following idea has been merged into this idea:
All the votes have been transferred into this idea.
The model rights screen currently provides partial insight into which roles have permissions on a specific object. The new objects screen provides insight into which new objects have been added. By revising the current model rights, we aim to make the combination of the two more insightful and make it easier to assign rights to new objects.
Additionally, we want to offer an alternative to the 'Assign rights' task, where we currently display the affected objects that can collectively be set to true or false. By introducing enrichments, developers will have more flexibility to choose which actions to execute.