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.

 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.

Câmera (getUserMedia) trava indefinidamente ao debugar apps mobile no Service Studio/ODC Studio para macOS — causa raiz: falta de entitlement de câmera no app Produto / Componente Service Studio para macOS / ODC Studio para macOS — Debug de aplicações mobile (alvo "Chrome (emulated)") Ambiente macOS: 27.0 (build 26A5378j) Service Studio: 11.55.78.64991 ODC Studio: 1.7.14.10418 Chrome: 150.0.7871.115 (única instalação no sistema, sem Beta/Dev/Canary) Máquina: MacBook pessoal (não gerenciada por MDM), câmera integrada (MacBook Pro Camera) Resumo do problema Ao iniciar uma sessão de debug no Service Studio/ODC Studio com o alvo "Chrome (emulated)", qualquer chamada a navigator.mediaDevices.getUserMedia() na página fica pendente para sempre — a Promise nunca resolve nem rejeita. Não aparece nenhum prompt de permissão de câmera, nenhum erro no console, e chrome://media-internals → aba "Players" nunca registra sessão de captura alguma (fica "No media player logs" indefinidamente). O mesmo fluxo/URL funciona perfeitamente quando aberto manualmente em uma janela normal do Chrome (fora do Service Studio) — câmera abre e renderiza sem problemas. Impacto Não é possível debugar (breakpoints, inspeção de rede/console via Service Studio) nenhuma tela que dependa de câmera/getUserMedia — inclui fluxos de reconhecimento facial, liveness, upload de foto via captura direta, etc. — usando o Chrome (emulated) integrado ao Service Studio para macOS. Passos para reproduzir Abrir um módulo mobile/reactive com uma tela que chama getUserMedia (ex.: captura de câmera para liveness). Na aba Debug Setup, com "Entry Module: (this module)" e browser "Chrome (emulated)" (única opção disponível), clicar em Start debugging. Navegar até a tela que solicita a câmera. Observar: nenhum prompt de permissão aparece; a tela fica travada (spinner/preto); nenhum erro no console. Investigação já realizada (causa raiz identificada) Passamos por um processo de eliminação completo antes de chegar à causa raiz — resumo dos testes: Verificado que getUserMedia é de fato chamado (interceptado via console) — a Promise fica em estado pending para sempre, sem resolver nem rejeitar. chrome://media-internals → Players: sempre vazio ("No media player logs") durante o travamento — a chamada nunca chega a criar uma sessão de captura rastreável. Descartado: constraints de câmera — constraints usadas (640x480 ideal) são suportadas pelo hardware (confirmado em chrome://media-internals → Video Capture: câmera enumerada corretamente via AV Foundation, múltiplas resoluções). Descartado: iframe / Permissions Policy — elemento de câmera não está em iframe. Descartado: perfil efêmero / modo Convidado (--bwsi) isoladamente — reproduzimos a linha de comando exata usada pelo Service Studio (capturada via ps aux durante uma sessão de debug ativa): /Applications/Google Chrome.app/Contents/MacOS/Google Chrome \ --remote-allow-origins=* --ignore-certificate-errors --no-default-browser-check \ --no-first-run --profile-directory=Default --bwsi --test-type \ --remote-debugging-port=9222 --user-data-dir=/ChromiumAdapterTemp/ \ --disable-search-engine-choice-screen Ao lançar essa mesma linha de comando manualmente pelo Terminal (usuário, não Service Studio) — incluindo --bwsi, --remote-debugging-port (CDP) e perfil novo em $TMPDIR — a câmera funcionou normalmente em todos os testes isolados e combinados. Ou seja, nenhuma flag do Chrome usada pelo Service Studio é, por si só, a causa. Descartado: política/permissão de câmera — testamos inclusive forçar auto-concessão via política gerenciada do Chrome (VideoCaptureAllowedUrls, aplicada e confirmada em chrome://policy com status OK dentro da própria instância do Service Studio) — não teve efeito; media-internals continuou sem nenhuma sessão registrada. Causa raiz encontrada — falta de entitlement de câmera no processo pai: Inspecionamos a assinatura de código dos apps instalados: codesign -d --entitlements :- /Applications/ServiceStudio.appcodesign -d --entitlements :- "/Applications/ODC Studio.app" Resultado: nenhum dos dois declara NSCameraUsageDescription no Info.plist, e nenhum dos dois tem o entitlement com.apple.security.device.camera. Ambos rodam sob Hardened Runtime (com.apple.security.cs.allow-jit, allow-unsigned-executable-memory, allow-dyld-environment-variables), sem App Sandbox completo. Quando o Service Studio/ODC Studio lança o Chrome como processo filho para o debug ("Chrome (emulated)"), o macOS TCC (Transparency, Consent and Control) atribui a decisão de autorização de câmera ao processo responsável (o próprio Service Studio/ODC Studio, via o mecanismo de "responsible process"). Como esse app nunca declarou intenção de uso de câmera nem tem o entitlement correspondente, o TCC não tem como resolver o pedido do processo filho — não autoriza, não nega, não mostra prompt algum. A Promise do getUserMedia() fica pendente indefinidamente. Isso explica por que a mesma URL, com as mesmas flags de Chrome, funciona quando lançada pelo usuário (via Terminal ou Dock) — nesses casos o processo responsável não é o Service Studio, então não há a mesma lacuna de entitlement na cadeia. Bundle IDs afetados com.outsystems.servicestudio.launcher (ServiceStudio.app) com.outsystems.odcstudio.launcher (ODC Studio.app) Correção solicitada Adicionar ao build macOS do Service Studio / ODC Studio: NSCameraUsageDescription (e idealmente NSMicrophoneUsageDescription, caso fluxos de vídeo com áudio também sejam afetados) no Info.plist O entitlement com.apple.security.device.camera (e com.apple.security.device.microphone se aplicável) na assinatura de código para que o processo Chrome filho, lançado para debug ("Chrome (emulated)"), consiga negociar corretamente a autorização de câmera junto ao macOS TCC. Workaround atual (client-side, sem alteração do produto) Não há workaround dentro do Service Studio. Para continuar testando telas dependentes de câmera enquanto o fix não sai: usar "Chrome (emulated)" apenas para a lógica antes/depois da tela de câmera; para a tela em si, copiar a URL gerada pelo debug e abrir manualmente em uma janela de Chrome iniciada pelo próprio usuário (fora do Service Studio) — confirmado funcionando em todos os testes, mas perde a sincronia de breakpoints visuais do Service Studio nessa tela específica.

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 :)

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 a Client Action is assigned as an event handler, it would be helpful to have a "Go to Event Handler" option that navigates directly to the associated Client Action. This would improve navigation and speed up development by making it easier to inspect and edit event handlers. The option could be exposed either through: The event handler dropdown menu A right-click context menu on the event property This enhancement would improve developer productivity and reduce the time spent locating event handler implementations.

When moving from DEV to QA it is asked to provide site properties or use the default ones. It would be nice to do this for REST and SOAP urls as well. We had a situation where the WSDL (and we didn't know) was pointing to PRD. We changed it on DEV to so that the intergraded SOAP was pointing to the development version. When deploying to QA we considered that this would point to DEV again. But it took the URL from the original Url WSDL. So it was pointing to PRD. When deploying from DEV to QA the siteproperties are shown and can be defined. It would prevent errors to do this for consumed integration REST and SOAP URLs as well. Especially for SOAP. For rest it is possible to define the base URL and choose DEV so that when deploying to QA it's not suddenly PRD. For SOAP it seems not to be possible to provide a base URL Example

 Problem Development teams often work across different geographical locations and time zones, while the OutSystems environment is typically configured with a different server time zone (for example, UTC or a customer-specific time zone). When reviewing timers, scheduler executions, logs, deployments, or other time-based activities in Service Center, users must manually calculate the current server date and time using external tools or time zone converters. This is inconvenient and can lead to confusion when validating whether a timer has executed or when correlating log timestamps. Proposed Solution Display the current server date and time prominently within Service Center (for example, in the header or footer). The display should automatically reflect the environment's configured time zone and optionally show the time zone abbreviation. Example: Server Date & Time: 10 Jul 2026, 14:35:42 UTC Benefits Eliminates the need to manually convert server time across different time zones. Makes it easier to verify timer executions and scheduler runs. Simplifies troubleshooting, deployments, and log analysis. Reduces errors caused by time zone differences. Improves productivity for developers, architects, tech leads, and support teams working across multiple regions. This small enhancement would provide immediate visibility into the server's current date and time, making Service Center more efficient for day-to-day monitoring and troubleshooting.

A centralized Developer Cheat Sheet for OutSystems Developer Cloud (ODC) would greatly help both new and experienced developers quickly understand and adopt the platform. Similar to the existing O11 cheat sheet, this should provide a concise overview of key ODC concepts, architecture, development flow, best practices, and differences from O11. It would serve as a quick reference guide to help developers ramp up faster and become productive in ODC projects with minimal learning curve. This resource would be especially useful for: New developers getting started with ODC Experienced O11 developers transitioning to ODC Teams looking for a quick refresher on core concepts Providing such a cheat sheet would improve onboarding efficiency, reduce confusion, and accelerate project delivery within the ODC ecosystem.