It would be really useful to be able to target an external database table to function and operate as a static entity within OutSystems. For companies that only want external data sources, this would bridge a current gap between the capabilities in and out of OutSystems. I am sure there are likely many data sources where there could be a desire to support this functionality but for my specific use case it would be Postgres.

Using OutSystems Semantic Search for community pages such as Forums, Ideas, and Forge brings a step change in how community members discover knowledge and reusable assets across the ecosystem. Traditional keyword search relies on exact matches, which often leads to incomplete or irrelevant results, especially in large content bases like community discussions, ideas and Forge components. Semantic Search, by contrast, understands intent and context, allowing users to find relevant answers even when terminology differs from how content was originally written. For the OutSystems community, this has a few clear benefits. First, it significantly improves discoverability. Community members can find the right forum threads, idea submissions, or Forge components without needing to know the exact naming or tags used by the author. This reduces friction and increases successful self-service. Second, it increases reuse and reduces duplication. Better search results mean developers are more likely to find existing Forge components instead of rebuilding similar functionality, and more likely to engage with existing Ideas rather than creating duplicates. Third, it improves community engagement quality. When users quickly find relevant discussions or solutions, they are more likely to contribute back, vote on Ideas, or refine existing answers instead of starting new fragmented threads. Finally, it future-proofs the community knowledge base. As content volume grows, semantic understanding scales far better than keyword-based approaches, ensuring that search quality does not degrade over time. In short, Semantic Search turns the community from a static repository into an intelligent discovery layer, making knowledge, ideas, and reusable components easier to access, reuse, and extend.

 Problem / current situation Component documentation is one of the main things a developer reads when deciding whether to adopt a Forge component, so its quality directly affects component discovery and adoption. Today the documentation editor is too limited to express real technical documentation. Its toolbar only supports bold, italic, underline, lists and links, with no headings, code blocks or tables. As a result, structured content collapses at authoring time. A parameter-mapping table (Parameter / Source in JSON / Description) is flattened into a single run-on line of bold text, section titles become plain bold text with no real hierarchy, and code samples lose their formatting. The published page faithfully reflects the editor, so this is not a rendering bug; the editor simply cannot hold the structure that good documentation needs. The authoring editor: no headings, tables or code blocks available. The published result: faithful to the editor, but flattened. Proposed solution Let publishers author documentation in Markdown. A minimal first step already solves most of the pain: 1. Upload a .md file , rendered directly as the documentation. And, building on that: 2. A Markdown editing mode in the editor, with raw input and live preview. Why this matters Better, more consistent documentation lowers the barrier to adopting Forge components, which is the whole point of the Forge. Markdown provides the structural elements the current editor lacks (headings, tables, fenced code blocks), which are exactly what documentation depends on. Markdown is the de facto standard for technical documentation, so most publishers already have content in that format and think in it natively. Nice-to-haves If the component has a linked repository, read its README.md as the documentation. Keep the current rich editor available, with Markdown as an additional option rather than a replacement.

Hi, I've run into this a few times. I would like to have the ability to do a simple query with an IN clause, without having to rely on advanced queries. It should accept a list of Identifier. Today we do ( from an aggregate perspective): SELECT * FROM {TASKS} WHERE id = 1 or id = 2 or id = 3 But it would be really awesome if we could do SELECT * FROM {Tasks} WHERE id in (1,2,3) This allows us to do some pretty cool stuff with Lists setc ( eg you can now shim some of the more advanced sql functionality without writing advanced queries). An example would be: myList = SELECT id from People WHERE OrganisationId = 2 SELECT * FROM {Tasks} WHERE personId = myList Which would be 2 actions, and somewhat faster/cleaner than the current way Writing an advanced query ( frowned up by my companies' best practices guide - and I've also found advanced queries tend to be annoying to manage ) Looping through myList and putting the outputs into another list, which is then passed around (this also has a few nasties - lots of DB hits (albeit small ones), and refreshing this with paging is a pain

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.

It's been years since dark mode was introduced, yet the icons in the list are still barely visible in Traditional. Could we make the icons the same color as the text or change the widget for the one in react? Previous image is traditional icon selection. previous image is react icon selection.

Service Studio already ships with a powerful but underdocumented headless execution mode. Through hands-on reverse engineering, we have confirmed and validated the following commands: -d (diff), -refresh, -u, -uu, -exportSettings, -importSettings, -cleanup, -removeChangeTracking, -runTests, -export, -import, and -silentrecover. These existing commands prove that Service Studio is architecturally capable of running fully headless, without opening a GUI. This proposal builds on that foundation to request ten new CLI commands that would unlock: AI-powered codebase analysis on .oml files without a running GUI CI/CD pipeline integration via GitHub Actions, Docker, and Linux environments Automated dependency management, publishing, and solution creation Programmatic introspection of modules, applications, elements, and SS_Keys These requests do not change the OutSystems platform concept or runtime. They expose what the IDE already does — through a command-line interface that can be scripted, automated, and run in containers. Proposed New Commands 1. ss list-apps — List Applications with Names and SS_Keys Problem: There is no headless way to enumerate the applications available on a server, along with their SS_Key (the GUID used by servicestudio:// deep links and LifeTime APIs). 2. ss list-modules — List Modules with Names and SS_Keys Problem: Modules are the atomic unit of development in OutSystems, but there is no headless way to enumerate them with their SS_Key GUIDs — the identifiers required for servicestudio:// protocol links and element navigation. 3. ss check-deps — Verify Module Dependencies Before Publish Problem: Before publishing a module, a developer needs to know if its dependencies are up to date, or if a producer module was published with breaking changes. The current workflow requires opening Service Studio, navigating to "Manage Dependencies," and manually inspecting each reference. There is no headless equivalent. 4. ss publish — Publish a Module Problem: There is no headless command to publish a module to a server. The current workflow requires opening Service Studio and clicking "1-Click Publish." This blocks full CI/CD automation. 5. ss republish — Republish a Module (Service Center Style) Problem: Service Center provides a "1-Click Publish" that recompiles and redeploys a module using its last published OML source, without requiring the source file on disk. This is critical for environment redeployments, disaster recovery, and CI/CD rollbacks — but it has no CLI equivalent. 6. ss list-elements — List All Elements of a Module by Name and SS_Key Problem: To use the servicestudio:// deep link protocol (e.g., to link directly to a specific action from a CI report or an AI analysis tool), you need the SS_Key of the element. Currently, the only way to get element keys is through direct database access or by reverse engineering internal API calls. 7. ss add-action — Add a Simple Action Using a Mermaid-Style Flow Definition Problem: Creating a simple server or client action in Service Studio requires opening the GUI, navigating to the correct module, and manually building the flow. For repetitive, pattern-based actions (logging, error handling, standard API calls), this is a barrier to AI-assisted code generation. 8. ss for Linux — Docker and GitHub Actions Support Problem: Service Studio is currently only available for macOS and Windows. This means CI/CD pipelines running on Linux (the default for GitHub Actions, GitLab CI, and most Docker containers) cannot use any Service Studio CLI commands. This is the single biggest blocker for full OutSystems DevOps automation. Request: Provide a headless Linux build of Service Studio — or a dedicated CLI package — that supports the full set of headless commands (existing + proposed) on: Ubuntu 22.04 / 24.04 (standard GitHub Actions runners) Alpine Linux (Docker optimization) Debian-based containers 9. ss delete-unused-refs — Delete Unused References from a Module Problem: Over time, modules accumulate references to producers that are no longer used — dead imports that slow down compilation, add maintenance overhead, and generate noise in -refresh / -u verification output. Service Studio can detect these via "Manage Dependencies," but there is no headless way to auto-clean them. 10. ss create-solution — Create Solutions Programmatically Problem: Solutions in OutSystems are the primary vehicle for managing and deploying groups of modules across environments via LifeTime. Creating and maintaining solutions is currently only possible through the Service Center UI. For teams managing complex multi-module deployments, the lack of a CLI solution creator is a significant DevOps gap. Why This Matters: The AI Analysis Use Case The combination of -listModules, -listElements, and the existing -d (diff) enables a use case that is currently impossible: AI-powered static analysis of OutSystems codebases without a running GUI. Current Gap: To analyze an OutSystems application with AI today, a developer must: Manually open each module in Service Studio Navigate through hundreds of screens, actions, and flows Copy/paste relevant information into an AI tool The AI agent can then generate a report like: "Action IsElegivelAntecipacaoDZero (key: 11ea244a-...) accesses the server on every screen load. Consider moving this to an Aggregate with proper caching. → [Open in Service Studio](servicestudio://-downloadAndOpen -eSpaceKey 6acebf97-... -elementKey 11ea244a-... -url bin.dev.myenvironment.com)" This is only possible if -listElements exposes SS_Keys in its output. Summary We are requesting 10 new headless CLI commands for Service Studio, with Linux support as the foundational requirement for CI/CD automation. The existing headless CLI (-d, -refresh, -u, -exportSettings, etc.) proves the architecture is ready. These new commands extend that foundation to cover the full development lifecycle — from introspection and dependency management, to publishing, solution creation, and AI-powered analysis. The OutSystems platform is already exceptionally powerful. These commands make that power accessible to modern DevOps and AI tooling workflows, without changing a single line of platform behavior.

 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.

Since we have the 1-Click Publish with Message, it would be great if we can set by default in settings, where Mentor to generate the message for us based on the changes made from previously published version.

Currently, in OutSystems Service Center > Factory > Modules > [Module] > Operation tab, users with "Open" and "Debug" permissions can view essential settings like Audit Stack Display, Run Mode, Debug Mode, Deployment Zone, and Light Logging. However, the critical "Light Process Execution" checkbox—which enables lightweight BPT for improved throughput—is not visible or determinable. This checkbox is shown in full admin views (first attached image), but hidden for Open/Debug users (second attached image), preventing developers from confirming if Light BPT is enabled without elevated access. Requested Feature:Display the "Light Process Execution" setting (checked/unchecked status) in the Operation tab for any user who can access module details via Open/Debug permissions. This ensures consistency: if a user sees module operations, all relevant toggles should be readable. Business Impact: Developers troubleshooting performance can't verify Light BPT without admin help, slowing debugging in teams with role-based access. Promotes self-service in Service Center, aligning with OutSystems' low-code efficiency. No security risk, as it's read-only visibility matching existing fields like Debug Mode. Steps to Reproduce: Log in to Service Center with Open/Debug-only permissions. Navigate to Factory > Modules > [Any module with Light Process]. Go to Operation tab—note "Light Process Execution" is absent. Please prioritize this for better module visibility in O11