This idea proposes a built-in visual tool that validates API requests and responses against their defined contracts, such as Swagger or OpenAPI specifications. The tool would automatically detect missing fields, incorrect data types, and deprecated attributes before or during runtime, helping developers catch integration issues early. By making API contract validation visible and easy to understand within OutSystems, teams can reduce production defects and integration failures without relying on external tools or manual testing.

Ability to input an expression while the debugger is running and have it evaluate it and display the results.

Currently, if we define a Sorting by an attribute, that sorting becomes unresponsive after introducing a Group By in the aggregate, as the sorted attribute is no longer part of the aggregate output . This does not raise any errors or warnings in the TrueChange Tab or any signaling in the workspace. I find that this is an easily overlooked situation that can lead to unexpected behavior or inconsistent results. I suggest the implementation of a typical Outsystems background validation that triggers a warning (written on the TrueChange Tab and a visual cue on the aggregate) whenever the aggregate's sorting references attributes that are not part of the aggregate output after a Group By, ensuring consistency and preventing silent issues.

Recently, a requirement forced me to use a Data action to fetch data from an external database.In Reactive, this means the Start Index is not available as a parameter, which means implementing pagination requires 10 times more work than a regular aggregate.The problem and solution are clearly explained in this forum post .It feels like there should be a more immediate way to do this, since OutSystems is pushing Reactive Web as the future, and integration with external databases as one of its main selling points.Thank you

I have noticed, and confirmed, that submitted Forge components in ODC Forge do not currently contribute to the community ranking. Additionally, it appears that there are no planned updates to address this issue. In my opinion, addressing this functionality is important to maintain the significance and value of both ODC and O11 when it's about the community ranking.

Hello community, I looked up if there was any idea similar to this, but I did not find it for Advance Query, just found it for the JavaScript editor. From what I came to suggest a simple idea for the Advance Query, have the numbering of the lines. It would help a lot. What do you think of this idea?Nuno Verdasca

 To aid in the current COVID-19 situation we are some persons who have started Society4Healthcare. Citizens and companies that are not able to participate in the clinical work are provided with a way to help the healthcare staff during the crisis through Society4Healthcare. By coordinating various tasks that help the hospital, its employees, patients, and their relatives we try to make daily life a little bit easier for them.We need to develop a solution for communication, enrollment, distribution of tasks and status reporting both per task and for the whole situation.

The new Data Grid is fantastic, but the fact that you have to add an ActionColumn and that that is the only one that can have an OnClick handler attached is quite limiting. It would be very nice to have the option to do the following:1. Add an OnClick handler to each column regardless of type2.Add an OnClick to an entire row so that they can click on any column and it triggers the handlerI would suggest that the Cell OnClick overrides the row one... but the individual cells click probably more important. Or potentially just allow one or the other.

When exposing a REST API, OutSystems generates a swagger.json documentation for the endpoint. Used data structures are documented in the "definitions" section where their required attributes are listed by their name in the array called "required". Because the swagger file is mostly relevant for systems other than OutSystems, the internal name of the OutSystems structure is not of interest. Instead the required attributes should be listed by their JSON name like in the "properties" section:

Currently all comments have the same color. In Dark Theme they appear black and in Light Theme they appear gray. This makes it difficult to distinguish important notes or identify who added them. The proposed idea is to allow users to define the color of their own comments so that in action flows it becomes easier to see who contributed. If full customization is not feasible an alternative would be to provide three predefined colors such as normal yellow and red to indicate severity or importance. This would help draw attention to critical comments and prevent them from being overlooked.