Hello everybody,Just like the title says.It would be great if, when we choose the Database type in an image widget, we could fill a "mime type" property (of type text) using an expression. This parameter shouldn't be mandatory in order to allow backwards compatibility.The behavior would be:- If mime type = "" then the platform does its "guessing game" like it does now;- if mime type is <> "" then the platform will use this as the mime type for the image to render;This way we can control the rendering if we know the exact mime type of the image, which we usually do since it's good practice to store it in the database. this will avoid issues with svg files not being rendered correctly and forcing us to use "external type" on the image.

CSS preprocessors have had nesting support for a long time, and it is now natively supported in CSS as well. Furthermore, many browsers already provide support for CSS nesting already: https://caniuse.com/css-nesting CSS nesting is a valuable tool, which has many advantages, including enhanced code readability and organization, which ultimately contribute to the improved maintainability and efficiency of the CSS stylesheets. Therefore, adding this functionality to OutSystems would be beneficial.

Please can you provide an option to use the uploaded Demo as a Try Now option, hosted on the forge server. Currently, if you don't have a corporate account/server you are willing to make publicly available, you have to use you personal account for the Try Now , but that expires and gets deleted every week or so, causing the Try Now to die.

When designing a REST API, it would become beneficial for the generated swagger file to include an 'enum' that defines possible values for parameters representing static entity identifiers. Consider the following scenario (see attachment) as an example: Within the REST API method, there exists an input parameter of the Entity1 identifier type. However, the generated swagger file merely denotes this parameter as a string without providing further elucidation. By incorporating an 'enum' into the swagger, additional clarity can be imparted regarding the acceptable values for this parameter. In this instance, the enum would specify: [a, b, c].

It would be good to be able to detach this panel from ServiceStudio, like a pop-up to define some values. Instead of having to expand it horizontally to edit expressions that are a bit large, we could have it open in a pop-up, edit the values in it and close.

1. Have a 'Yearly' selection Currently, we can select 'Daily, Weekly, Monthly' when we are configuring when timers are suppose to run. It will be a nice to have, if a 'Yearly' selection is available as well. There are some jobs which are only required to run once a year. Currently, we can only build a check, in the logic of the timer, to check whether whether it is a new year before continuing the logic. 2. Have option not to automatically run timer, when it is set from 'Inactive' to 'Active ' We have encountered a situation before, when we need to set the timer to Inactive for debug purposes. As the application is already live in PROD, naturally the status of the timer is Active. Then we found there was a bug, as such, we set the timer to Inactive in PROD, while we are still trying to fix the bug. After fixing and when app was deploy to PROD, we have to switch the timer back to Active. However, once we switch, the timer automatically runs again, even thou it is not the correct time to do so. So our end users panicked, as they know the auto emails, reminders etc, shouldn't be set out during that time of the day. End-users being end-users, they might not understand that we are just trying to fix a bug and then re-activate the timer

When right-clicking Publish in ODC, if the options for Dev, Test, and Prod environments were displayed directly, developers could quickly navigate to the corresponding environment URL without having to search for it manually.

When creating a new app I would like to have descriptions whereever possible. Some are currently set, some ar not, e. g. see screenshot.

I have the need to organize applications and modules in multiple ways and want to be able to add multiple labels to the application. So that I can filter by label(s).E.g. label Orders to identify all modules that are in the Orders domain. Another label could identify the module layer and jet another one to identify the team responsible for the module.I would be great if there was a link to Discovery for these labels so that the architecture is defined inside service studio.

The help page you are given a link to when publishing from ODC to the Forge is completely blank. Can someone add some details please?