Show who are the users online and currently working in this shared environmentThis future will be really useful to improve joint working culture.If the user is publishing then it will show their status as publishing.If they just working on it then it will show their status as online.If the user is not using the environment then it shows his status as Offline.It will help other users in the shared environment to avoid publishing at the same time.

Currently, components created under ODC are not listed in the My Assets section of Forge — only O11 assets are visible. Additionally, when selecting both “My Assets” and “ODC” in the filter, it still shows all ODC assets instead of only the ones created by the logged-in user. It would be great to fix the filter and include ODC components under the My Assets section to maintain consistency and help developers easily track their contributions.

It is difficult to track down a version of a forge component once you have installed it in your environment and the component receives new updates from the community.It should be easier to check how far behind I am in adopting a newer version of a particular forge component by just going to Service Center or best in LifeTime itself.Based on a trustable hashing algorigthm, why can OutSystems not determine if the package hash for the version of Forge component is matching with a signature with a published component and if so flag it to me easily. If the match does not happen then tell me that I have customized the copy of forge component so it is not possible to track it against the public repository.

Currently, OutSystems documentation provides a list of compatible browsers for generated applications. However, verifying this compatibility at runtime requires developers to manually implement logic using functions like GetBrowser or GetUserAgent from the HTTPRequestHandler extension. This approach has drawbacks: Manual Maintenance: Developers must update their code whenever the official compatibility list changes, risking outdated implementations. Difficult Diagnosis: Identifying issues caused by unsupported browsers can be time-consuming, as seen in a real case where support intervention was required. Suggestion:Introduce a built-in Action in the platform to automatically verify browser compatibility using OutSystems’ maintained compatibility list. Benefits: Simplifies development by removing the need for custom maintenance. Speeds up issue diagnosis related to browser compatibility. Enhances user experience by providing immediate feedback if an unsupported browser is detected. IsBrowserCompatible() -> Boolean The Action would return True for compatible browsers and False otherwise. Additional functionality could provide details about the detected browser and compatibility issues.

In OutSystems, when a user tries to access a specific page without an active login session , they are redirected to the login page. However, after successfully logging in, the user is not redirected back to the original URL they attempted to access. Instead, they are sent to the default portal or home page. This behavior can be inconvenient from a user's perspective. Users are forced to manually navigate back to the desired URL, which disrupts their experience, especially in scenarios where deep links or bookmarked URLs are involved. Proposed Solution: Modify the authentication flow so that if a user is redirected to the login page due to an inactive session, their original URL is preserved. After a successful login, the user should be redirected to the URL they initially attempted to access, rather than the default portal or home page. Benefits: Improved user experience and satisfaction. Enhanced support for deep links and bookmarked pages. More intuitive behavior aligned with common expectations for web applications. This enhancement would make OutSystems more user-friendly, particularly for scenarios requiring frequent logins or when users access the application via shared links.

Currently, the Default Value field in Site Properties is limited to a single-line input with no option to expand the editing area. This makes it cumbersome to view and edit longer values clearly. An expandable or multi-line editor, similar to the one used for editing Expressions, would greatly improve readability and usability.

It would be great to have a native Service Studio for Apple Silicon (M1/M2 Arm CPUs), instead of running them through the Rosetta translation layer. The performance and power consumption are not ideal at the current state.

Similar to when I drag a screen action to the screen and OutSystems automatically creates a button on the screen, it would be nice to drag a client action and have OutSystems create a wrapper screen action (that calls that client action) and a button on the screen

Hi,I believe that can be a good improvement to have the possibility to disable an REST/SOAP method from our exposed APIs.With that we can maintain versions with methods under work without the need to have different versions and, I believe it's more practical :)  (like the "disable" capacity in the action flows).The idea is to have them under the API but not available to use and not present in the generated documentation.Best regards,Ricardo Pereira

I would like to be able to add comments to True Change warnings when I hide them, so the other developers on the team know why I hid them. For example, if I make a mandatory field non-mandatory, and hide the warning, I want them to know what my reason is so they do not just change that setting. We have had a number of problems in the past because someone followed True Change warnings when they should not have. :( J.Ja