GUI - extension to developer mode

@Boudewijn , can you provide some examples when/how this should be used? What is the business case?

While troubleshooting an issue, or developing specific code, it is very handy to use the client application as a database browser/editor instead of going through compiling the specifice updatestatement to reach a state where functionality can be tested.

It is not always handy to make those changes in the meta model, either for tracebility of actual changes or for the risk of not putting it back in the original state. (Making a throwaway-branch for testing/reproducing a specific state would be an option, but a lot heavier than ticking the box ‘disable layout on this screen for this session’)

I want to list a few points that we should consider if we decide to implement this feature, not to argue against it, but to make sure that we implement it correctly and what that would involve.

• Development mode in the Windows GUI is currently determined by the INI file and anyone can turn it on or off. We should consider looking at the users marked with ‘Developer mode’ in IAM instead, allowing administrators to determine which users have access to this feature.
• In the future, the Windows GUI will run on top of Indicium Universal and the GUI will no longer have a say in whether or not default and layout procedures are executed or not. This feature will quickly become an Indicium Universal feature. Again, this would require us to use the Developer mode list in IAM instead, otherwise any client can claim to be a developer.
• Since it is not possible to circumvent default and layout procedures in Indicium Universal, their importance and reliability has grown as well. They can be used to ensure data integrity and even authorization without the need of triggers as a fallback. There is some risk involved in allowing them to be bypassed, even when only whitelisted users can do it. We should consider only allowing it if the user has access to developer mode and Indicium is running in development mode as well.

Thank you for your input, Vincent.

Your last point is very valid: with defaults and layouts being so difficult to circumvent, chances are people will be using them to ensure data integrity. Developers might keep that in the back of their minds, but it will become more and more risky to run a GUI with defaults and layouts that the application depends on for data integrity, turned off.

I hate to realize it, but I think my suggestion in its current form should be closed. Lucky no one ‘liked‘ dit anyway! ;-)