I see a lot of spam posts in the forum. Add a button so we can report this.

Several of the patterns provided by OutSystems UI can be used as replacements for native widgets (e.g. Input or ComboBox), but since they are not native HTML elements they cannot be bound to a Label and take advantage of the Is Mandatory text decoration nor the focus switch when the Label is clicked/touched.It would be an interesting language development if any Block could optionally define one of its widgets as the default widget for this purpose though! Blocks with a default widget defined would then be available for selection on the Label's Input Widget dropdown.OutSystems UI and any other pattern library could then make use of this and integrate seamlessly with the existing Form behavior.Idea sparked by this post : https://www.outsystems.com/forums/discussion/64101/outsystems-ui-dropdownsearch-is-not-a-valid-label-input-widget/

 TLDR: CSS Layers are a way to define order of precedence in the case of multiple cascade layers. The suggestion is to implement a way to define these layers, to further improve the development of custom themes and layouts. Why?Being able to define cascade layers allows the developers to separate stylesheets into a hierarchy of priority. Quoting the MDN article:"[A cascade layer] enables the creation of simpler CSS selectors because you do not have to ensure that a selector will have high enough specificity to override competing rules; all you need to ensure is that it appears in a later layer."In practical OutSystems terms, this means that the OutSystems UI stylesheet could sit in an early layer while the Custom Theme of an application could be placed in a later layer, hence avoiding overriding conflicts with existing rules. Furthermore, in environments where a Custom Theme exists, but a superset theme is applied to specific applications, conflicts of specificity could also be avoided. How?This layer definition could be placed in a per-CSS file basis: it's just another parameter like "Name", "Description", "Public", etc. The layer order (or precedence list) could be defined in the Theme Editor, or be set in Service Center.

 Problem: The procedure of changing themes in OutSystems is by and large a process of trial and error. Developers need to update styles and check each screen separately, which takes a lot of time. Enhancement: Introduce a live preview editor for themes that reflects changes automatically on all screens. Developers are free to change colors, fonts, and styles and they can even choose not to publishing or navigating between screens and yet see the result. Benefits: Time is saved as the user is not required to test and switch between screens constantly. The customization of themes is brought about in a quicker manner and with less effort. The look of the app is consistent throughout the entire ‍‌‍‍‌‍‌‍‍‌application.

GDPR requires organizations to implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk. CMK supports this requirement by enabling strong encryption practices, which are critical for protecting personal data against unauthorized access. Currently enforcing customers own encryption key is only available through application level which requires extensive implementation cost that will delay projects and cause customer frustration, when their other resources in Azure or data platforms like Snowflake support CMK out of the box. As part of an enhanced security add-on it would be great with such functionality at platform level.

Implement an additional functionality that allows searching for all uses of a CSS class across all consumer modules of that stylesheet. The front-end teams would greatly benefit from this measure, as it streamlines development and enhances maintenance processes.

When tagging someone in the OutSystems Forum using @, multiple people with the same display name can appear. This makes it unclear which person you are actually replying to. To improve clarity and avoid confusion, I suggest these options: Enforce unique usernames that each user can set for themselves. Display this unique username with name consistently across the forum (profile, comments, and mentions). In the mention dropdown, show both name + unique username so members can easily identify the right person. Or We can also go with an easy step, which in the forum email should be displayed with the name, and also in the mention dropdown This will make communication smoother and ensure that members always tag the correct person in forum discussions.

In O11 we can end other debugging sessions by republishing the module. However, this does not work in ODC. It would be nice if there is a button next to each "active session" in the Users section of the Debugger tab in ODC Studio. With the click of the button, the debug session of the other account would end. This way, we can make sure that the app continues running normally without hitting the debugger activated by other accounts, in case the other users are unable to end their session. Security-wise it would be nice to give this option only to organizational accounts with elevated roles, e.g. the tech lead role.

I love the free personal environments that OutSystems offers the community free of charge! It offers a lot of freedom to develop and test applications without the burden of contaminating your own business environments.On various circumstances I had problems with my personal environment. It was offline for days and had to raise a ticket with support. It would be great if I have the option to reset my personal environment to the initial state. Meaning that all customizations and configurations on my personal environment are wiped.

It would be nice if we could cancel the publishing solution process on service center.