Sometimes we are publishing an eSpace and we start working in another eSpace (which perhaps needs something from the other eSpace being published) and we have to keep switching tabs to check if the publish is already done.If we could have that information on the tab we wouldn't need to keep switching between eSpaces.Please see an example in the attachments

 O que é isso? Uma ferragem colaborativa integrada à plataforma sobre os desenvolvimentos podemos comparar, comparar e aprender com métricas de desempenho de aplicativos do mundo real desenvolvidos no OutSystems. Problema que resolve: Os envolvidos frequentemente enfrentam gargalos de desenvolvimento, mas não têm uma referência sobre o desenvolvimento de aplicativos semelhantes. Não há um local centralizado para compartilhar práticas recomendadas específicas de otimização. Cada desenvolvedor "reinventa a roda" testando soluções isoladas. Como funcionaria: 1. Contribuição de métricas anônimas Os desenvolvidores enviiam dados de desenvolvimento de seus aplicativos (tempo de resposta, consultas lentas, uso de memória) Informações confidenciais podem ser anonimizadas Sistema se compara à comunidade: "Seu aplicativo é 30% mais lento que aplicativos semelhantes" 2. "Receitas de Performance" Biblioteca de soluções testadas: "Reduzir consultas N+1 em ListRecords" com comparações antes/depois Votação comunitária: qual solução funcionou melhor? Integração com controle de versão: em qual versão do OutSystems cada solução foi eficaz? 3. Desafios mensais "Otimizar esta aplicação problemática" - colaboração comunitária Recompensas simbólicas: emblemas, reconhecimento, destaque de perfil 4. Integração do Service Studio Plugin que exporta automaticamente métricas de desenvolvimento Um clique para compartilhar com uma comunidade

I would like to propose the inclusion of a logging capability for the SOAP requests sent and received from any WebService in the scope of an eSpace.Meaningful information to be included:-Server and port-Date + time-SOAP messages sent and received-User-Originator (process, flow, ...)And a log viewer that enables the search for Web Services invocations based on:-Service name-Date-Originator-UserThe Soap messages (sent and received) should be presented in XML.What we gain:-easy way of detecting configuration errors (wrong server, ...)-easy way of validating the input sent, for user input errors-easy way of validating the output sent from the back-end system via the web serviceThanks,Francisco Vasco

Please can we have the option to clear a date picker that's native to the widget itself. Like the Dropdown search widget does

Hello there,It would be nice to open multiple eSpaces in Service Studio by pressing shift from the top to the bottom (or vice versa) when we go through the "Open from Environment" option.Also it would be good that, when opening the eSpace the cancel button would work.Thanks.

Video Example for Each And Every WidgetOutsystem  consist of many widgets , give some demo videos to each and every widget how it works. it will help to outsystem beginners and they know how effectively use that .Thanks in Advancekishorevijay

In Service Studio, while searching Forge component, search keyword not get storing in client/session variables.If I search "weather" in Service Studio's forge and click on one component to review that. After clicking "Go to list", the searched keyword went missing and shows home page of forge.Now It's needed to search the same keyword again and again.So I think it will be good if that search keyword will be stored in Client/Session variable.I herein attached the screenshots and recorded videos of that.

Right now, once a secret site property is created, you can’t see or validate the actual value—especially in production environments, where developers don’t have access and only a dedicated support team configures the values. This creates a risk: if the value is entered incorrectly, there's no easy way to check or confirm it. Benefit: It would help with auditing and validation. Teams could verify that the correct value is set, even in restricted environments, and avoid errors caused by misconfiguration. Thanks

Having identical icons for client and server side built in functions makes it tricky to know which one to use. For example the ListFilter shown below - how is one meant to know which you can use client side and which you can use server side? I remember it like this: client-side one is on top because the request always comes first from the user on the client side - i.e. the first/top one. But I think a slight variation in icons would not be a big change but would be beneficial.

Statistics on how much time spent on developing an application/module in Service StudioIt will be useful to analyze ourselves  or our team on how much time they will work on the specific application.It will be useful to improve our future works