The scenario is an attribute that is decided not be used anymore in an entity, but its deletion is not a good policy at that point.The only way to "deprecate" is adding a comment in the description, which is not a safe solution because it doesn't prevent developers to keep using it.So there could be a property in the attribute (called Deprecated) that could grey out the field and warn about its usage in SQLs and other actions.

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.

The main idea is simple:- You could limit the modules that consume this module, this would mean that no modules outside that set of modules could ever reference anything from this module.This means the module owner(s) can in effect limit the consumers modules.I believe this would greatly help some medium/big factories.

When you're working on the OS PaaS environment, the time that is displayed when a module is deployed is the server time. I would be nice to have a setting in lifetime where we can set our own timezone so for our company the correct time when an application is deployed is shown.In some cases we need to check when something was deployed and we need to 'calculate' when it was deployed. Als when people don't know it's a different timezone the will be some communication errors.It's that small thing that make life easier (-:

It would be great to have these events in a SOAP webservice also, so we could also manipulate Headers and RequestText of the SOAP Message.

Enhance the OutSystems Entity Actions Wrappers Accelerator to: Centralize validation logic: Automatically create a dedicated wrapper for validation rules specific to an entity. Consolidate Create and Update: Generate a single, unified server action that handles both entity creation and updates, utilizing the centralized validation wrapper for consistent and maintainable logic." This approach would: Reduce code duplication: By separating and centralizing validation logic, developers avoid maintaining identical or similar rules in both Create and Update actions. Improve maintainability: Changes to validation rules can be implemented in a single location, ensuring consistency and reducing the risk of errors. Simplify development: Streamline the development process by requiring fewer actions and reducing the need to manage duplicate logic. This enhancement would significantly improve the efficiency and maintainability of applications built with the OutSystems platform.

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

When we add non-mandatory attributes to structures (for example input/output structure of a Service Action), there will be no impact on the consumer modules ONLY if the added attribute is a basic type. You can read this in the documentation Handle Changes in Exposed Functionality , 'The following changes made in the producer do not have impact on the consumer modules: ' Add an optional Attribute (basic data types only) Structure In my perspective, there should also be no impact on consumers when adding non-mandatory composite/complex attributes like adding a record, or a list, or list record... Here is a scenario we are facing right now. We use Service Actions instead of internal REST API's to promote a loosely coupled architecture. There is benefit in using Service Actions as the platform handles the security and findability of Service Actions, whereas with REST API's, you have to do it yourself. All our Service Actions communicate with input/output Structures. When we want to add a non-mandatory structure to the output structure of the service action, then the consumers are impacted. Now both applications have to be deployed together, which complicates loosely coupled deployment strategies. Here is an screenshot to describe the issue.

I don't know if there is somewhere else for this... https://learn.outsystems.com/training/journeys/web-developer-exam-2993/best-practices-for-building-screens/odc/6729 There's explicit instruction elsewhere in the training NOT to use Check###Role() on the enabled button, but to only use it on the visible property, because you can just hit F12 and enable the button.

The idea is to right click on a reference and choose 'Manage Dependencies', open the 'Manage Dependencies' window already with the filter filled with the module name. We would have a big gain in performance.