When I was looking at the download page, I noticed two version naming systems are currently in use:For the IDE, on the downloads page we see the release "tag" (eg: "Development Environment 11 - Release 12").But then, on studio, we see the version number (eg, "11.0.406.0")Again, with platform server and lifetime this scenario repeats: on the download page the tag, on the software the version number. This creates a bit of confusion when one is trying to understand, e.g., which version of the platform server to download.By looking into this article detailing the version naming system and this article detailing the release lifecycle, one can reach the conclusion that the tag on the download page refers to the release life cycle ( the when ) and the version number details the type of changes on the release ( the what ).My suggestion is first and foremost to use a single naming system both on the software and the website, to avoid confusion. But going a little bit further, I would suggest adopting a simpler system where version number is based solely on the release (which in the end is the only thing the user cares about).  If as the article I previously linked suggests, there is predictability on the release cycle, then similarly to Ubtuntu, one can even make the date part of the versioning system, naming both the release and the version after the date, and if necessary, additional numbering for minor patches.Additionally, it would be really, really nice if we had exactly this page , but with the download links on the tables.Thank you for your time,Filipe

To have a 'Find Usages' function for API clients created in ODC portal. When we expose API thru libraries, we can add ClientId and ClientSecret as settings. Then we will add the values, in the actual consumer app settings in ODC portal. Since there can be a lot of application using same ClientId and ClientSecret, it will be useful to have a 'Find Usages' for the actual API client created. This will allows for easy governance, and also ensure the correct app is using the correct API client.

As of now OutSystems Community profile score is based on user participation in forums, training, sharing ideas and forge. I know many leaders who are contributing for Community Growth via usergroups. Also many users actively participating in usergroup session. If we allocate some points for usergroup activities (organizer, speaker, quiz winner, participant ) it will be great. Just a wish 🙂

I have been using images that I have uploaded to the images resource folder but every time I have to select an image all I have is the name of the image as a reference , It would be nice to have a thumbnail next to the name of the image to allow me to preview the image before adding it to the screen/weblock. Images folder There should be thumbnails next to the names of the images

It would be great if the reactive data grid provided associative columns or dependency between columns.For example, there are two dropdown columns, one called Function and the other called Role. When a Function is selected, the dropdown Role will display only the roles belonging to the selected Function.I think it is a very important functionality, used in a lot of cases, so it would be very good having it in the reactive data grid.Thank you

Builtin round function should enable one to indicate the round precision: Round(number, precision) where: Number is the value to round Precision: number of decimal places after round (if positive), number of position to the left side of the decimal separator where to round (if negative).

Scheduled deployment is a smarter, more efficient alternative to manually clicking the deploy button. By automating and scheduling deployments, organizations can improve consistency, reduce errors, and optimize resource usage. Adopting scheduled deployment as part of a robust CI/CD pipeline ensures smoother, more reliable software releases, ultimately leading to better operational efficiency and user experience. Benefits of Scheduled Deployment 1. Reduces Human Error Manual deployments rely on human intervention, increasing the risk of mistakes, such as deploying the wrong version or skipping a critical step. Scheduled deployment eliminates this risk by automating the process. 2. Ensures Consistency and Reliability With manual deployment, inconsistencies can arise due to variations in execution. Scheduled deployments follow the same automated process every time, ensuring reliability across different releases. 3. Optimized for Off-Peak Hours By scheduling deployments during low-traffic periods (e.g., midnight or early morning), teams can minimize disruptions to users and reduce the risk of downtime. 4. Frees Up Developer and Operations Teams Developers and DevOps engineers no longer need to be present at odd hours to manually deploy updates. Instead, they can focus on more critical tasks while the deployment occurs automatically. 5. Enables Continuous Deployment (CD) Scheduled deployment is a key component of Continuous Deployment (CD), allowing teams to release updates frequently without manual intervention. This results in faster iteration cycles and quicker time-to-market for new features. 6. Supports Rollback and Disaster Recovery With automated deployment, rollback strategies can be implemented to quickly revert changes in case of failure. This ensures better disaster recovery and system stability.

My idea is to keeping the existing behavior but with the possibility to turn off automatic fetching data.Suggestion: Button like Test button (advanced queries) inside the aggregator to be able to disconnect or connect to the server.

Add a small icon decoration so that on the espace tree we can differentiate which actions are public on an espace. While you're at it do it also for the ones that are functions...

Currently, we use Cordova plugins hosted in GitHub repositories and integrate them into our mobile applications to generate builds but this will expose the plugin code in public, As an alternative, we can include the plugins as ZIP files within our module to keep the code from being exposed. However, when the plugin size is large, including it as a ZIP file can lead to timeout issues during mobile app build generation. Hosting the plugin on GitHub resolves this issue, but it introduces another challenge: the repository must be public for the MABs to access it. To address security we would prefer to keep these repositories private. Since mobile builds are handled by MABS (Mobile Apps Build Service), there is currently no straightforward way to grant secure, controlled access to private repositories. Proposed Idea: Provide a mechanism to allow controlled and secure access to private repositories during mobile app build generation. For example: Support authentication methods (e.g., access tokens or SSH keys) Allow configuration of private repository credentials within the platform Thank you,