Problem : When an ODC environment is configured to use the ODC Cloud Connector, all REST integrations must use https://secure-gateway: as the base URL and pass the real target URL as a custom Host header. Since the secure gateway URL is the same across all environments, it adds no configuration value — yet it must be stored as a Setting, cluttering the Settings list with a technical implementation detail that developers never need to change. Idea : When the ODC Cloud Connector is active for an environment, ODC should recognize the Host header as the effective base URL for that integration and surface it in the Settings tab instead of (or in addition to) the raw base URL. This way, developers configure the meaningful value (the real target URL) and the platform handles the secure gateway routing transparently. Benefits : Cleaner Settings list - no noise from gateway URLs that never change Easier onboarding - developers configure what they understand (the real API URL), not infrastructure details. Consistent with the spirit of Settings as environment-specific, meaningful configuration values.

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.

At the moment only OutsystemsUI has a static color entity, and mobileUI does not. Using the static in a mobile app creates an unavoidable warning in your code. Ofcourse different solutions might apply, but overall this should not cause a warning by default.

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.

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

Hello! We love the new 1-Click-Publish completion sound. However, it does not sound when the Service Studio is minimized or not in focus. We'd love to be able to switch to other applications/tasks and still hear that sound effect. While you're in there, a stretch goal would be customizing the sound effect. We have certain other technologies we could sync the sound with then to get our Developer's notified more effectively. JSP

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.