Hi Catia,

  Yes pre built action would be nice but you can currently check to see what mode the environment is using the Activation Entity from the System espace. Do a filter on Info="Server Mode" and text="Development" and if it finds a record then you are in development mode.

There are a couple of other values in that entity which may also be useful such as "LicenseType"

Hi Cátia,

Thank you for your idea. 

Can you please elaborate on the uses cases that you want to fulfill and why do you need this information for those cases? You speak about timers. what are those timers doing that can't run in production? do you have more examples?

Either way, I will mark this as "on our radar" to understand if there is more demand for this.

Cheers

Hi John,

Thank you, yes that is one way of doing it, amongst others, but if you are working at a factory for example, you can’t reference system tables without special permissions.

Hi Tiago,

I said timers, but this can be used in several different cases. The idea is to avoid that functionalities, that were built solely for the purpose of helping the developers and maybe testers do they’re work, can be active in production. 

For example in a user list we can have a “Login as” action that allows us to login with that user, or we want to allow users to erase data from the application because the tests they are executing need a “clean set of data”. All these kind of functionalities should never be available in PRD.

Hi Catia, yes agree that it isn't ideal, just mentioned in case you needed something now.

@Tiago, it is useful for a number of reasons. One particular is where you want to have logging, test information and other details to help with testing. For example displaying extra fields on a user screen such as ID's that you don't really want showing up in your production environment. Using Site properties is a way around this but as Site properties aren't shareable across applications it is a lot simpler to just check what environment you are in. 

Have a look at this forge component: https://www.outsystems.com/forge/component-overview/489/environment-sticker

Hi Nordin,

Environment sticker uses system tables. Does not fit the use case.

Hi, Cátia and everyone else that contributed to the idea,

Thanks for detailing the use cases where you would use this kind of capability. However, I can see a lot of other use cases were just relying on Development, Prod and Non-Prod may not be sufficient. For instance for load testing, done in QA or UAT environments and which are typically set as non-prod environments but even though you may want to track some extra logging to have more detail to act upon. Also for QA and UAT processes, you would also not want to display particular parts of screens but could eventually require tracking extra logging that can then be used for debugging and troubleshooting.

We believe that having a setting like Site properties provide the necessary versatility to implement what makes sense to each particular project, application, or development team.

Thanks for contributing with your feedback.