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.

I would like to suggest adding a microphone/voice-input option to Mentor in ODC Studio. Currently, developers interact with Mentor by typing prompts or commands. It would be highly useful to have a microphone button that allows developers to speak their requirements directly, with speech automatically converted into text and submitted as the Mentor prompt.

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

An often-occuring issue is that user click on an action twice, which causes an action to run twice. This leads to very nasty issues where data is created and/or processed twice. One way to prevent this, is to wrap your Button into a 'Button Loading' widget, and adding an IsLoading widget to the page. It would be nice to support this in an easier way, either by: Adding a property to the button that adds 'IsLoading' behaviour to it Add ButtonLoading widgets around all your button widgets in your apps Any other ideas to achieve the same result?

Hi Outsystem Team, I believe that OutSystems Table Grid should also have some features like Data Grid such as column picker. Sometimes we have to use Data Grid just for the column picker type features. Thanks, Vijay M.

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.

Since we have the 1-Click Publish with Message, it would be great if we can set by default in settings, where Mentor to generate the message for us based on the changes made from previously published version.

Would be a (minor) quality of life feature if you could bind a label to an input if you simply drag and drop it from the tool box on the left straight on the Input widget. For example here, this widget is bound to a "Max records" local variable, to control how many records an aggregate returns. If I drag the label on to it, it could do several things: Add the label on top of the Input Set the Input Widget automatically on the Label properties, and give it a name like "InputName_Label" Set the text for the label on a 'best guess' case, depending on what the input is bound to (for example here, Max records) This could work for all other input type widgets: text area, switches, checkboxes, dropdowns, etc.

When checking a forge component, the only way to inspect what this component offers (screens, server and service actions, blocks, entities, etc...) is to install the component first. It often happens that the component in question is not what a developer wanted or had in mind. Showing a structure view of a component's public elements directly in the Forge Component's detail page, before downloading, would make it much easier for us to be able to assess preliminarily whether a component fits our needs or not, without having to download it first. The idea is to have this step automated, without having to rely on the manual documentation (that often is missing from components), similar to the automatic documentation that Outdoc offers for target applications but of course that exact level of detail won't be necessary. A high-level preview of the elements would perhaps be enough.

Introduce a configuration mechanism that allows to enable or disable Code Quality analysis for specific applications and libraries. This capability would make it possible to exclude test applications, sandbox applications, or temporary applications, preventing them from affecting overall code quality metrics. With this configurable approach, we would gain greater control over which artifacts are included in quality measurements, ensuring that reports remain accurate, relevant, and focused on production-relevant systems.