Restrict the use of (System) entity User to read only by developers



To have more control on the use of the (System) entity User by the developers in the OutSystems Digital Factory, I would like to have a way to restrict the use to read only, that is, so that the entity actions to change the content of the entity would not be available.

And for that matter, extend this to all other (System) entities (Espace, etc) of the OutSystems data model.

I know that we can in LifeTime define Roles with specific permissions, like "Reuse & Monitor" or "List", but this functionality in LifeTime, as far as I am able to understand it and use it, does provide what I need.

--Tiago Bernardo

Created on 19 Dec 2018
Comments (5)

Changed the category to Lifetime

Only if it can be switched off. We need to implement our own User management model and have to write to quite a few of those tables (users, Groups etc)  so making them read-only would be a major disaster for us.

Agree with John.

That said, sounds like you have some developers who need significant education, retraining, or to be terminated, if you cannot trust them to write code that writes to Users. Especially since they can call the equivalents in the Users espace which will not give you any additional protection either.



John Williams,

The intention is not to _completely_ restrict the possibility to change the content of the User system entity. The intention is to be able to restrict it to some (most of) developers. Developing, for example, your own User Provider espace will still be possible for the appropriate authorized developers.

Justin James,

It is not about (only) educating your developers, it is about being able to enforce rules to avoid unwanted situations (as your infrastructure might be shared by several teams from different origins for which you have no complete control) and also because people are not perfect and make mistakes. You might know that, because you are an educated developer and still (by mistake) you were sometimes publishing in PROD (until the OutSystems platform got the feature to prevent/warn for when the developer is publishing to a Production environment).

Let me try to explain better:

Currently, in LifeTime, as soon as you give a developer (an IT-User) "Change & Deploy" access to an application, that developer is able to make references to the system entities (the metadata of the OutSystems platform), in particular the User system entity, without any restrictions, that is, from that point the developer is not only able to query the content of those entities but also to change the content of those entities, and of course probably with many undesired consequences.

(In the next screenshot the entity actions for the User entity are not shown but they are automatically available when you reference the User entity).

If somehow there was the possibility to restrict the access to the system entities to Read-Only access to some developers that would solve the problem, but this is not possible (as far as I know, even in P11).

In LifeTime you can restrict access to developers (or grant access) by application, like in the next screenshot where "Reuse & Monitor" as been granted to the developer to application Users.

The most you can do in LifeTime is restrict access to the "System Components" application but this not include the system entities (like the User system entity).

I hope I made myself a bit more clear...

--Tiago Bernardo

Tiago -

It's one thing for a system feature (automatically re-connecting to the last environment you connected to connecting someone to PROD when they thought they were in DEV) that works 99.9999% of the time exactly as-needed surprise someone once a year and they make a mistake.

I will need to hear some legitimate, real-world examples of what kinds of problems the current situation has actually caused for me to think anything other than "you have some really bad developers on your staff". Because other than writing tenant or user management, there is no reason to write to any of these entities, and those tasks should be given to an experienced developer due to the security and stability risks associated with them.

I just cannot imagine any kind of situation where a developer that should not be writing a piece of code due to a lack of experience is actually writing that code, and the solution required is a technical fix. That's a process and management problem. It's like you are asking for a solution to people speeding by limiting all vehicles to 100 km/h unless the person driving them is a police officer.