Inheriting from system.user

4
We're using an employee object which is inheriting from the system.user. In a NewEdit form all attributes are filled, but the active(boolean) attribute cannot be checked. When you set this boolean on true and save, next time it will be false. When I look in the database, the value is set to true. So I cannot set my employees active/non-active, simply because a dataview or datagrid cannot read from this object. How can this be? Edit: I've fixed it by adding the system.administrator module role to all the roles which are supposed to see the the form with the active attribute. But I don't think this is right solution in terms of security. The system.module is now secured since the 2.5 release, but to make thinks working I have to give system.administrator roles to simple roles in our application. So i'm using a workaround to get around the improved security. I don't think this is correct way of dealing this problem. Why can't the system.user have READ rights on the System.User object? Who could explain this, because there is no clear documentation about this topic.
asked
1 answers
2

The security settings of the System module are fixed, and a System.user object is considered a private thing of that specific System.user. To work around this, you can derive from System.user and adjust the security, adding members if necessary. For example the default Administration provides the Administration.Account object.

Your proposed workaround is indeed insecure, and far from ideal.

The way to work with these restrictions is using Microflows, since they do not need to obey the security settings. For example you could add an _Active attribute, and copy its value in a before commit, or create a microflow 'Make active' which does something similar and couple it to a button in your form.

answered