OutSystems is powerful, but some of its best features are hidden from developers. This forces us to create complex workarounds for standard patterns like Publisher/Subscriber (Pub/Sub). Pub/Sub is essential for modern apps, allowing different parts to communicate without being directly connected. While debugging the application in client side, it has been discovered that OutSystems already has a built-in Publisher/Subscriber functionality. This feature is powerful and works perfectly, as demonstrated in this Working demo - PubSubDemo This internal API can be accessed with a simple piece of JavaScript: require(['OutSystems/ClientRuntime/modules/PubSub/Publisher'], function (Publisher) { window.Pubsub = new Publisher.default("DemoApp"); }); By adding this as a required script to a module, we can unlock a native Pub/Sub instance, allowing different blocks and components on a screen to communicate with each other without being directly coupled. This is a game-changer for building complex, modular, and responsive user interfaces. The existence of popular Forge components like "PubSubEvents" clearly demonstrates the community's need for this exact functionality. My idea is simple: Elevate this hidden Publisher/Subscriber functionality into an official, documented, and fully supported feature of the OutSystems platform.

It would be great to have a small “Neo Insights” section within our forum profile. This section could display how often Neo has helped us, its response accuracy, and even suggest learning materials based on our previous questions. It would make Neo feel more like a personal learning assistant that evolves alongside each developer’s journey.

Hello!So we already got the dark theme on the service studio, awesome :DBut I thought about having a dark theme option for the OutSystems portal.Stay with me, I know that exist a lot of extensions that can make it happen, but still is ugly and it's not so good and there is a lot of bugs.Some examples.Let me know what "you" think.Kind Regards,Márcio

Allow customize permissions to IT User using Lifetime. Today we have some permission pre-defined such as:Full ControlChange and Deploy ApplicationsOpen and Debug ApplicationsMonitor and Add DependenciesList ApplicationsAccessNo AccessCreate ApplicationsAdd System DependenciesManage Infrastructure and UsersManage Teams and Application RolesBut when we need people to be able, for example, to just change Site Properties and/or run Timer in a Production environment, we need to grant the "Change and Deploy Applications" permission which also allows you to change and publish an application directly in Production.

When I set a description to a timer in service studio, I can't read this description at the timer in service center. It would be nice to being able to read the description of a timer in service center so that I don't need to open the eSpace to see where the timer was used for.

Show in the previous result, the number of records returned by the query when using the test variables.As shown when testing with SQL.It would help to verify that the query logic is running as expected.

Hello,As Forge applications grow in use, the support cases grow as well. Take a look for instance to the XML Records component which has over 100 comments in a show-more-10-records-per-page version. There's no way to search on a support case list if a similar support case has been open. Eventually, this is a reason for why such components have eventually the same question posed time and time again.

In one of the latest verions of OutSystemsUI the structure ErrorMessage has been added. This is in a nice default format for passing errors around the entire application. We also want to make use of this structure in our backend so that we can have one uniform error handler in the frontend. Both OutSystemsUI and our own actions all provide the same structure with the error information making it easy to consume and handle. But by doing this we create a dependency from our backend to a frontend component and that feels sniffy. OutSystemsUI could change in the future or even be replaced with something else. Better would it be if this structure would be moved to the System entity and by doing so both OutSystemsUI and our own components could consume that structure and in case of changes nothing is broken because the replacement could (and should) also reuse the ErrorMessage structure.

For integration with third party build tools it would be nice to have a command line tool to create a solution programmatically.In this scenario the build would included the following steps:Create a osp file based on eSpaces (oml files or Espaces from an OutSystems environment)Install the osp file by means of the osp tool

Hello,The idea is to create a new role or option for the created users that have or do not have access to the "CSS inline" / theme and layout and other front end options to ensure that only authorized users can change the front end issues and guarantee the good experience and best practices.And create a "find all" css inline in the module so that it is possible to locate and change or not the code.Thanks