When we request a trusted badge review for a component in the forge, there is no way to cancel that request. There are many reasons why I would want to do that, such as: I made a mistake in the version I submitted I want a new version to be reviewed instead of the one I submitted originally I received feedback from other components and now I know that my other requests will be rejected for the same reason. Being able to cancel in these situations would remove work from outsystems staff

Development environments in large projects can easily end up having a high number of published versions by module.In many scenarios searching for a specific module version where some specific logic was implemented is essential.In these cases, the possibility to filter the Other Versions list by date would make this process faster.

Union of Simple Queries

It would be interesting to have a Null() function that replaces NullIdentifier(), NullDate(), and NullTextIdentifier() in OutSystems, like traditional programming.

Like overriding the endpoint URL of APIs through service center, we should be able to turn off documentation on the Production environment for security reasons.This is currently being configured in the Service Studio (Yes or No values) and will be carried over to deployed environments. Not really safe to do publishes in the production just to turn off documentation.

When I have a block containing a pop up, that pop up will be collapsed in instances of that block. When I have a placeholder inside that pop up, and I need to add a significant amount of design inside that placeholder, using the widget tree only gets very tedious. Therefor I would like to be able to display the content of the block, or at least the placeholders.

 As a developer, I want to assign set 3 values to a single Site Property for all environments. This will dramatically speed up a deployment, where you won't browse several modules and change Site Properties depended on Environment. It is common practice when we set a Site Property value to production value by default, and change it manually in Dev and Test. In this case we kind of avoid a "human error" if we forget it during deployment. But sometimes we have several such properties, e.g. SomeDomainUrl , which should be different for each environment. I would suggest to inherit the practice we use in not low code: we might have several configuration files for each environment, e.g.: appsettings.json appsettings.development.json appsettings.test.json That means during a deployment build process the compiler will choose corresponding settings. How I see it: When you add a new Site Property, you can add (+) two more for tst and prod . If a developer does not add it, they are the same by default. Like that: Site Property : fromEmailAddress Value : "noreply-dev@mydomain.com" (+) tst Value : "noreply-tst@mydomain.com" (+) prod Value : "noreply@mydomain.com"

What do you need?Retry options for REST integrations. They should includeThe number of times a retry should be performed before failing.A duration of time (in seconds) to wait between each retry.Specify which status codes to perform retries on. For instance, you may want to fail immediately on 400 (Bad Request) or 401 (Unauthorized) but would like to retry on codes such as 408 (Request Timeout), 429 (Too Many Requests), 503 (Service Unavailable), 504 (Gateway Timeout) etc. This should be a list of status codes that can be specified at the developer's discretion. Potential Stretch Option - Callback for OnBeforeRetryAttempt to allow the request to fix a potential expected failure or log additional details for troubleshooting.What could it improve?It would increase the stability of REST communication and reduce application errors caused by transient errors on a REST API that the OutSystems developer may not have control over.Who would benefit from that?Anyone that uses REST integrations could benefit from this additional control.

Hi,In Outsystems we have a concept called Applications that are a group of modules that are grouped.To be compliant with Outsystems architecture it's normal to have 2/3 applications that refer to the same business application (as you can see in the image).To allow better governance I suggest creating a new concept called cluster that will improve:Log analysis by business applicationDependencies by business applicationData flow by business applicationTechnical debt (AD) analysisArchitecture reading

Hi,Sometimes we have to clear the entire local storage on Mobile Local for the sake of User Switch.For this scenario right now we have to manually call all the Delete Actions of all Entities when user log-out.Would be quite easy if outsytems provide an action to clear all entities in an optimized &  fast way.Thanks