Disable mutation data from within lookup popups

Hey Arjan,

Have you considered creating a Dynamic model procedure to create variants for each table that has a lookup reference to it? This procedure can also set settings and screen type correctly for the variant and even automatically assign the variant to the lookup reference if not filled. This could be a great script to be shared in the ThinkStore.

Another option would be to create more specific roles to ensure that your users cannot mutate any data they shouldn't. Is there a specific reason why you haven't implemented this option?

Hey Mark,

Unfortunately a Dynamic Model procedure in this case will not solve my issue. If I create a variant using such a procedure that means that within this variant I cannot change anything else, since it will be removed and recreated after generation of my model. Often you would like to make some additional configuration in such a variant. Include this configurations in the dynamic model is not an option either.

Preventing this using roles is also not an option. These users are allowed to make changes to these objects, just not via lookup popups.

The reason why is that these users are more likely to change the wrong record via lookup popups, they are not the most technical users and are having a hard time understanding the concept of a lookup popup.

Hi Arjan,

Unfortunately a Dynamic Model procedure in this case will not solve my issue. If I create a variant using such a procedure that means that within this variant I cannot change anything else, since it will be removed and recreated after generation of my model.

This is not necessarily true. Unless the Dynamic model procedure fills the Generated column with 1, the objects will not be removed. With this procedure, you can safely create objects if they do not exists based on the Primary key of the specific table. You can even make use of either the create_tab_variant or copy_tab_variant stored procedures for easy creation of new tab variants and thereafter update settings using update statements. I still think this would be a better solution to the challenge.

Could still be an easy project(-version) setting instead of a dynamic model thing.

@Mark Jongeling,

I do not want to turn this into a dynamic model procedure. Somethings that are very specific for one client can be created by setting up a dynamic model procedure. However a feature like this, seems more like a project(version) setting. This dynamic model will become way to complex and very difficult for others to use as well.