When are we gonna have a option to access the metadata from a OML file?In my case i need to generate report for instance, all screens and their input/output parameters to a given Espace.This information exist only in the OML file. Therefore only the Service Studio is able to open it. Maybe some component which could translate it?I think its important feature for enterprise grade Frameworks like Outsystems.With best regards,Slavi Popov

Hello everyone, I’d like to suggest implementing a mechanism for approving forum solutions. With more and more community members actively contributing and answering questions, it would be valuable to have a way for a champion, MVP, or staff member to officially approve a solution and/or provide authoritative feedback. This could include notes such as suggested improvements. I believe this would be especially helpful for newer or beginner members, who may not yet have the experience to evaluate multiple answers and might default to the first response, even if it’s not the most accurate or optimal one. Such a feature would help ensure higher-quality guidance across the forum and make it easier for users to identify reliable solutions. Additionally, there are many older topics that have received answers, but the topic creator never officially marked a solution or confirmed whether the answer worked. This often leads to members replying to old or inactive threads, which can unintentionally push newer and more relevant topics down the forum list. I’ve seen cases where newly created topics end up on the third page of the forum because multiple old threads were resurfaced. With an approval mechanism in place, moderators could review these older topics and officially approve a solution where appropriate.

Even though the ODC Portal is in its early stages, what do you think about adding some colours to the Stages dropdown? (Example: Dev=Green, QA=Yellow, Prod=Orange) We've been told that the ODC Portal is the "substitute" for the Service Center and Lifetime applications. In this ODC Portal, the Admin can basically configure and deploy applications for all the Stages . Although this is great because it has everything in one place, the absence of colour coding can lead to misconfiguration because the user might not notice he/she is in the wrong Stage doing the configurations. Attached are some prints to support the idea.

Moving forward would there be any plans to support rollout of web applications in the form of Progressive Web Apps https://developers.google.com/web/progressive-web-apps/ https://developers.google.com/web/showcase/This allows no installation, fast web applications, service worker, greater productivity and SEO.

In Client Web applications, when performing custom validation on a Form, developers cannot directly set Form.Valid manually. This creates a limitation in advanced scenarios where validation conditions can't be fully handled by the built-in validation framework. For example, if a developer wants to invalidate the form based on a business rule such as: Number < 100000 there’s no way to directly set: Form.Valid = False Instead, developers are forced to: Create an extra local boolean variable to store the validation result Reuse the same condition again when checking whether to proceed or show an error This results in code duplication, reduced maintainability, and extra steps for logic that should be simple. A better approach would be: Allow manual control of Form.Valid — enable developers to set it to True or False inside client logic flows or expressions Or introduce a built-in method like Form.Invalidate() that can be triggered conditionally, without relying solely on form input widgets This would: Simplify complex validation scenarios Reduce the need for extra variables and duplicated conditions Improve logic readability and maintainability Let developers manage validation state more directly

While using the Upload widget, it would be really helpful if there were built-in properties to set allowed file types (like .pdf, .jpg, .docx, etc.) and a maximum file size limit (in MB or KB). Right now, we have to write custom logic or JavaScript to validate these things, which takes extra time and can be tricky for less experienced developers. If these options were available directly in the widget, it would save time and make file uploads more secure and user-friendly out of the box.

 Allow line breaks in translated text fields within the built-in translation interface. Currently, when editing static text directly on a screen (e.g. by double-clicking a text element in Service Studio / ODC Studio - we are using both now), it is possible to insert line breaks. These line breaks are preserved and correctly rendered on the page. However, when translating the same text through the translation interface, the translation field is limited to a single-line input. There is no way to insert line breaks in the translated version of the text . As a result, any original formatting that relies on line breaks cannot be reproduced during translation. The only current workaround is to export all translations to Excel, manually locate the relevant rows, insert line breaks inside the Excel cell (Alt+Enter), and then re-import the file. This process is slow and cumbersome, especially when correcting or updating a single translated text after a small change in the original. It also increases the risk of accidental edits, typos, or inconsistencies when handling the export/import file The translation interface should support line breaks directly in the translation field (for example via a multi-line input or allowing a keyboard shortcut such as Shift+Enter). This would allow translators to preserve the intended formatting of the original text without relying on the Excel export/import workaround. Thank you very much in advance!

Hello All,JavaScript has had ES6 and ES7 syntax since a couple of years. The new syntax provides some good features like lambda syntax, the 'let' keyword, the 'const' keyword, template literals etc.While some old browsers do not support all of the syntax, there are libraries like 'babel.js' ( https://babeljs.io/ ) which transform modern JS to ES5 (the usual JS syntax).It would be great if the OutSystems product allowed using modern JS directly in ServiceStudio.OutSystems can integrate the babel.js within the platform - so that it can convert any modern JS syntax to ES5 (older JS when required for old browsers, already most modern browsers do support ES6 , but not all..).Advantages:1. Developer productivity with modern JS will be very good. Many forge components rely on JS and JS libraries and having support for modern JS will be great.2. Modern JS is helpful for writing easier to read and maintainable JS code.3. On the mobile front in OutSystems - apache cordova for the mobile plugins is JS based - so supporting modern JS would be a win over there too.

[Service Studio]If you are developing a Big Action full of Sub-Actions all with plenty of mandatory entry points, it would be useful to have a new Sub-Folder area where no Validations were made on the "Work in progress" Actions/Functions that way you could publish the eSpace until all the new actions could be used.That area would also include Finished and Validated Actions with no usage anywhere else within the eSpace

The reactive web is taking its first steps, but right now it's not fully mature and doesn't have all the functionalities of the traditional web.It would be great to have a gap analysis document  which states what is now missing from Reactive compared with the Tradicional web. It would help to make the decision whenever a new application is going to be created. Should we go for Reactive or Tradicional?Example: Lifetime analytics not fully working in Reactive. Translations are not yet ready in Reactive. Etc.