Service Studio should have new, separate "Tests" tab.This would enable integrating tests to any eSpace and would minimize required overhead for testing any action, including private actions.Why?Testing your code is more professional than not testing.Unit testing should be minimal extra effort for developer, because otherwise tests are usually not done.Publishing new code could be controlled - you cannot publish untested code, or code which has some failing tests, for example.Test code should never go to Production environment.Testing is good.How?Tests are integrated to eSpace/module oml file.During code generation process, actions from "Tests" tab would create a separate .NET project and this project would be a friend assembly (internalsVisibleTo attributes configured) for main project to compile.1-Click Publish deployments with tests could start from (currently underused?) personal area (or another IIS folder), where tests would be run.Depending on how tests go and how is decided in additional configuration, deployment would continue to Public area or show an error in Service studio.This way, creating unit tests would be as effortless as when creating unit tests in any other modern programming language - just few clicks away. There could be also accelerators to generate unit test actions or "system events" to initialize/teardown test runs.Currently, writing any tests to private actions is also either impossible or exposing some unwanted/test related code to production environments.It's a big change, but from discussions with makers/experts @ ODC I've learned this should not be too far-fetched idea to implement. Maybe for P12, please?Another, possibly the simplest way to enable testing / production code separation without massive modifications to existing compiling process could be a capability to define another espace as " friend " espace. This per-espace setting could reveal internal (=OS private) actions to the another espace marked as a friend and thus enable referencing these otherwise out-of-the scope actions for testing purposes.If done like this, feature could be achieved using small amounts of .NET reflection trickery or previously suggested InternalsVisibleTo attribute (that has been around since 2002 release of .NET 2.0).Security-wise, there should be no problems either, (albeit a bit more work during compilation) as friend assemblies can be defined as signed assemblies, too.Personal opinion, but this topic is really heavily connected with OS small book #2, #5 and #7.

Upgrade the standard File Upload widget to a comprehensive "File Manager" component. Beyond just uploading, this widget should natively support: Removal: Easily delete a file before submission. Review: Integrated Preview and Download actions for subsequent users in a workflow. This eliminates the need for developers to build custom "Download/Preview" patterns every time they create an approval-based form, providing a seamless experience for both the uploader and the reviewer.

OutSystems is actively supporting integration of ODC and O11. Currently, the only way to consume logic from each other is to use a REST API. This is cumbersome and portentially unsafe. It would be much easier if the Platform allowed consuming Service Actions instead (which in essence are also REST methods, but easier to use). So O11 logic could consume an ODC Service Action, and ODC logic could consume an O11 Service Action. This would greatly enhance easy operability, and be secure out of the box.

 To be able to set conditional breakpoints instead of breaking everytime.

Many times, when developing an application, I have an action within a block that I need to trigger from the screen that uses it. I had many cases where this happens. For instance, let's say I have a button that will validate the the form within a block in the parent screen. I want to handle the validation just inside the block, and will need to perform the validations within it. Or when you want two blocks to react with eachother, but don't want to join them on a single block. Or even when I just want a button to perform an action that is inside the block. Currently, there are indeed some workarounds for it: Creating a dummy variable on the screen, that works as block parameter that will trigger the OnParametersChanged. This one gets complicated when you already have an OnParametersChanged set, but want to run just a single action; Handle all the data from the parent screen using events; Create an invisible button within the block, and set the onclick event to an external from the class or Id of the button - similar to this documentation page: https://success.outsystems.com/documentation/how_to_guides/front_end/how_to_call_a_block_action_in_a_mobile_screen/ But things get complicated when you have many blocks inside the screen, and this end with many "dummy" screen variables, too many screen actions just to perform an action that is already inside the block, or refactoring the screen/block to join them against your own will, and increasing development time. In blocks, the communication between the block and the consumer screen block are triggered by Events. It would be nice if we had the possibility to consume a screen action from the block, like setting it to "public" so you can run it from the parent. And would be way easier to manage this actions from blocks inside a list, so you would only need the row number to trigger the action. This issue brings many questions on the forum as well, like: https://www.outsystems.com/forums/discussion/73627/how-to-run-action-block-from-main-screen/ https://www.outsystems.com/forums/discussion/102238/triggering-save-action-from-block-using-a-button-on-screen-in-outsystems/ It would make the development cleaner, easier to follow good-practices and follow the low-code philosophy.

Working with multiple environments simultaneously is a standard practice, but Service Studio makes it hard to distinguish between them at a glance. Currently, a developer must check the status bar to know if they are in Dev, QA, or Prod. Introduce an "Environment Theme" feature where we can assign a specific color to each infrastructure. If I'm in Production, the Service Studio UI (or at least the tab bar) should have a distinct color (e.g., Red). Add the environment name as a prefix to the tab title (e.g., "[PROD] MyModule"). This would prevent accidental changes in the wrong environment and significantly improve the UX for developers managing complex lifecycles.

It would be nice if OutSystems provides us with an instruction guide or video on how to implement an existing reactjs component in OutSystems reactive app or library module. There are many react UI components available for example to show data in a tree, that are not implemented in OutSystems UI. Using as guide on how to do this, the community can extend the usability of the reactive web development more easily.

Hello Everyone. When we access the Application > Applications tab in Lifetime and want to extract all versions of existing applications from all applications in the OutSystems Factory, we don't have the option to download everything. My idea is this: to have an Export button like "Download Versions List" Button on this page to automate this time-consuming process. See the image below. Best Regards, Paulo Russo .

Currently I can choose only one module to open, and sometimes when I need to open multiple module I need to click open from Environment for each module I need to open and so if user has an option to multi select, it can choose modules he needs to open and they can start opening rather than clicking open from Environment or ctrl + O. I face this issue when I need to refresh the n number of consumer modules. Even user have this option on application under its modules section.

Create a system action in ODC where a message can be logged to the error log. LogMessage will log a message to the general log. O11 has the AsynchronousLogging extension that has a LogError action, but ODC does not. In ODC, an application can log to the error log by throwing an exception. However, there are occasions when the application needs to continue processing. In this scenario it would be useful to log a message to the error log and continue operation.