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'.

• What if a new column / task parameter / report parameter is added after setting up the rights?
  • For this question I'm behind the idea that Robert-Jan presented
• If you give a table rights because you need a column look-up, you now only get the display. Should this change?
  • For this scenario I'd say having the display is enough when the only reason for the rights is to view the column look-up
• 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.
  • Personally I wouldn’t go that far either with granting rights to the parent of the given object. What I would like though is when granting rights from the parent, in this case the table, that when granting table task rights the task parameters are also included

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.

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 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.

This is planned to be resolved with the Roadmap 2025 H1 efforts.

Hello everyone!

The first part of the changes mentioned in this topic has been implemented in the Software Factory as soon as the current sprint has been completed, which means it will be included in the 2025.1 release. This development concerns the revision of the Model rights screen. The detail tab page New objects that existed within this screen has been removed and has been replaced with its own menu item called New objects. This menu item can be found under Access Control.

This New objects screen will show insights in both the existing as well as the new model objects that have been introduced in the current model version.

By default the screen will be filtered so it only shows the new objects, however when one wants to compare these new objects to the settings of the previously existing objects, the corresponding prefilter can be disabled to show all objects.

Additional visual support for the developer is included through means of status icons and badges, indicating if and how many new objects still need to be verified.

Some examples of what this looks like:
 

This is the first step towards an easier process of granting rights to an objects and its children.

The follow-up step of including child-rights when granting parent-rights will be included in the follow-up of this development.

Hopefully this provides some insight into the new developments regarding this topic and I hope you all look forward to having this in the new version of the Software Factory !