Restricting user from modifying users table.

Hi all,

is there a way with which we can restrict all users (developers) from modifying users table ?

I don't want any of the systems entities be visible to a developer while developing an application.

I managed to restrict all system entities except users table which by default comes out with creation of a module. So, even if it is visible, i want to restrict the developer to use the users table to modify or delete any of its content.

Thanks & regards,



Do you actually store live data in the dev environment? And don't want your developers to see this?

Nonetheless, I'm firmly against restricting access to the devs, trying to work on a system with limited access is incredibely frustrating. 

They should already be restricted from doing so in the Production environment.

Hi Claring,

there is nothing "Frustrating" in this. Every organization has got some process and protocols which need to be followed. By the way we have wrapper methods that can be used to access the data, but i am more concern on modifying system entities data especially USERS.

We welcome 'Solutions' to this concern!

So you are afraid that your developers could potentially break the system by modifying the user entity right?

That being said, I don't think it is possible to restrict them from accessing default system entities, functions, components etc.

I guess that leaves the option of having to check the entire source when deploying to test/prod in order to make sure your developers didn't do anything which would alter the system.

Or as an alternative solution, you could create another Entity yourself, in which you extend the existing users entity.

Inside this entity you could set a protect rule to make sure that an entry from the existing User entity isn't able to be deleted.
You then add limited wrappers with only get functionality, however this still leaves the problem of them being able to add or update any existing rows in the User entity.

Hi Debasis,

I can't think of a standard solution to this, so you mighty need to use some more unorthodox methods, like a DBA creating a trigger on the physical table in the database. If you don't administer your own database, then I'm not sure what could solve this for you.

Of course, changing database objects created by the OutSystems Platform itself is definitely not recommended and may cause other undesired behaviour. Test thoroughly and use at your own risk...

really depends how you want to organize stuff.

- multi-tenancy is a possibility

- multiple userproviders

- have a shadow-userprovider with your own users-table...