The new option to publish with an added message is very nice, but too often I forget to click the dropdown arrow and accidentally Publish normally. Because there is no way to add a message after already publishing, this can get quite annoying. I suggest a simple extra configuration checkbox in the Service Studio Preferences to optionally change the "with Message" option to be the default. When enabled, Normal publish should still be available through the dropdown arrow.

Provide a secure, built-in read-only data viewer for ODC Production environments, allowing authorized users to view entity records without creating custom screens or APIs. Benefits: Faster troubleshooting and support Reduced development effort

Be able to create a unit test for a Server / Service / Client (?) / Screen (?) action that shall be executed without developer intervention, for regression purposes.

Hi Outsystems teams, Since the OS charing static entity for 1 AO, to save some cost for clients, in many projects, we hardly use static-entity even though it should use Static-entity for many purposes. We need to use alternative ways to implement the static concept, like using structure, hardcode... This led the development become more complex in design, implement, and more hard-code used, but we can't spend 1 AO for just 5 records stored in static-entity like status, type, etc... Actually many projects opened just to Delete all static entity from the code to save cost. From begining we've learnt how to use Static entity, and in real project we need to learn how to not use Static entity to save AO, this make static entity very dead. Can Outsystems consider to lower the price of AO somehow like count it 1 AO = 3 or 4 static entity, or consider make it free if there are < 10 record store in static entity, this would be a great thing for Outsystems developers and clients. Thanks :)

 The Problem When an External Logic component is published to the Forge today, the author uploads a pre-compiled binary. A git repository link can optionally be included, but it is purely decorative, OutSystems does not verify any relationship between the linked source and the uploaded artifact. This means that as a consumer, when you install an external logic Forge component, you are executing code you cannot verify. You are trusting the author's word that what they linked on GitHub is what's actually running in your tenant. This is a real supply-chain risk — even with good intentions, a compromised account, a build-time dependency swap, or a simple mistake can result in consumers running code that doesn't match the published source. The Proposal Require that External Logic components submitted to the Forge are cryptographically linked to a public git repository at a specific commit, and that the submission process enforces this linkage — not just documents it optionally. The flow would look like this: The publisher develops and uploads their External Logic to their tenant as today (nothing changes here) When submitting to the Forge, they are required to provide a public git repository URL and a pinned tag or commit SHA that corresponds to the uploaded binary The Forge stores a SHA-256 checksum of the uploaded artifact alongside the source reference Consumers can inspect the source at the pinned commit, and optionally build it locally to verify the checksum matches what they'll be installing This doesn't change the upload mechanics, it adds an auditable envelope around what's already there. This is the same trust model used by mainstream package ecosystems: go install github.com/user/repo@v1.2.3 — builds from source at a verified tag cargo install --git — fetches and compiles from a git ref crates.io — stores checksums and optionally verifies builds server-side Why This Matters Transparency: consumers know exactly what code runs in their tenant, down to the commit Supply-chain integrity: eliminates the "binary black box" problem; no more trusting an uploaded artifact blindly Community accountability: published source is public and auditable; the community can catch issues before they spread O11's Integration Studio was transparent by design, you could open an XIF and see exactly what was there. ODC External Logic moved us forward in capability but took a step back in auditability. This proposal closes that gap, in a modern and supply-chain-secure way.

 Problem: There's no way to rate or review Forge components, making it hard to judge quality or reliability before installing one. Proposed Solution: Add a star rating and comment system to each Forge component page - visible in listings and search results. Restrict reviews to users who've installed the component, and let authors respond to feedback. Benefit: Helps developers choose components with more confidence, gives authors useful feedback, and improves trust across the Forge ecosystem.

Hello Our organization currently maintains a large-scale application developed using OutSystems Traditional Web. At present, we lack a formal mechanism to monitor the real-time volume of active user sessions within the Production environment. Acquiring this data is essential for optimizing production support operations and determining appropriate schedules for release management. Thank you.

Currently, it is not possible to conditionally add or remove an HTML attribute using the Attributes property. The only way to achieve this behavior is through custom JavaScript. It would be very useful to have the ability to conditionally render an attribute based on an expression, similar to how the Value property currently supports expressions. This would allow developers to avoid rendering empty or unnecessary attributes in the generated HTML. The feature could work as illustrated below: This enhancement would be particularly valuable for accessibility requirements, enabling developers to more easily implement dynamic ARIA attributes and other accessibility-related properties, ultimately improving development efficiency and speeding up delivery.

When checking a forge component, the only way to inspect what this component offers (screens, server and service actions, blocks, entities, etc...) is to install the component first. It often happens that the component in question is not what a developer wanted or had in mind. Showing a structure view of a component's public elements directly in the Forge Component's detail page, before downloading, would make it much easier for us to be able to assess preliminarily whether a component fits our needs or not, without having to download it first. The idea is to have this step automated, without having to rely on the manual documentation (that often is missing from components), similar to the automatic documentation that Outdoc offers for target applications but of course that exact level of detail won't be necessary. A high-level preview of the elements would perhaps be enough.

Currently, the FormatDateTime() function formats a DateTime value based on the specified format, but the result is returned as Text . This requires additional conversions when the value needs to be used in date calculations, sorting, filtering, or database operations. It would be beneficial to have a function that allows formatting a DateTime value while retaining its DateTime data type, reducing unnecessary conversions and simplifying date handling.