Like many others of you, I read from the ideas, we also have problems indicating changed/new labels.When you add a new label, the label will be indicated 'To be defined', but when you copy another label, the translation will be same a the old one, and it's it's indication is 'Translation'. And also, if you change a label, the indication won't change back to 'To be defined.So, how can we identify that a label have to be reviewed? We have hundreds of labels to translate and every Sprint there are some changes. It's impossible to review all the labels again and again.Since my idea of putting those changed labels back into 'To be defined' is rejected by OutSystems since users only doing typos have to put everything back into 'Translate'  again... I got a better idea now. Let's add a last_changed_date(time) so we can sort on that field and only check the labels we changed recently.Please like this idea to get this into attention of our Outsystems IDE developers.

 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

When using the OfflineDataSync it's currently not possible to add an Input to the TriggerDataSync action. For cases, where you only want to synchronize data for specific record (e.g. an Order with it's orderlines) you cannot send the OrderId along with the TriggerDataSync. I always need to use a work-around in my OfflineDataSync switch by doing something like: A: Substr(SyncUnit,0,11) = "UpdateOrder" and in the client-action: IntegerToIdentifier(TextToInteger((Substr(SyncUnit,11,100)))) in the TriggerOfflineSync I then enter this in the SyncUnit: "UpdateOrder" + OrderId B: use JSON (de)serialize logic as SyncUnit variable. It would be way easier if it's possible to add the custom input parameters (e.g. OrderId) to the TriggerSyncAction and use it directly in my OfflineDataSync.

We frequently have problems with our database CPU being over-utilised by one or two resource-heavy queries and then our users experience poor performance and time outs because the database can't keep up with demand. We don't think one or two queries should be allowed to bring down our whole database, even if they are resource-heavy. Could I suggest some functionality which would allow us to cap the resources consumed by an individual query, please? Or something which reduces the resources allocated to a particular large query if there isn't enough resource available for incoming requests? Perhaps the Resource Governor available on SQL Server?

 Add a possibility to do a Distinct Select from a field on a Simple Query.

We could have the option of, within the context of espace in Service Studio, perhaps in the Module menu, "Move Espace to ...", the same action that occurs from within the context of the Application, where you choose which application to use for the space be moved.This is useful, for example, when cloning a space, either to test some functionality separately or even to definitely split the architecture (This would avoid, for example, having to go to Independent Modules and then move again).

Since a while now, it's possible to convert an Aggregate to an SQL query. This is a great feature, but it has a number of limitations. For one, discoverability is low. Why not add it to the context menu when clicking an Aggregate?Secondly, the limitations listed are annoying, if Service Studio can run the query on the database, it should be able to convert it to SQL. The limitations listed: The option to convert an Aggregate to a SQL element will only be available if your Aggregate doesn't include: Structures in Sources Calculated Attributes Group By attributes Dynamic SortsIt would be nice if this feature would be improved, so that all (or most) of these limitations are gone.

 It would be great if any new ODC forge component could be listed in OutSystems Community newsletters , as daily digests.

Create a Built-in Function Switch, under the Miscellaneous tab. It makes it easier for developers to understand the intended behavior than having several if's chained. It may cause fewer errors, since it is not necessary to check the same variable/condition several times.

Hi!The idea is:Set a module as Internal/Private relative to its application so that its public elements can only be consumed by other modules in the same application.When an element is set to public in a module it becomes available to be consumed by all other modules (with the exception of some rules that relate to the type of modules).But sometimes the public elements of a module should only be consumed by other modules in the same application because that module is just a supporting/internal module; its public elements should not be consumed by other modules external to its application.Being able to set a module as "Internal" or "Private" to its application to achieve the goal above would allow better control on the dependencies, improve on the architecture, and prevent incorrect consumption of public elements. I give two examples to support this idea:1) Integration Builder produces per integration two modules: An "IS" module and a "DRV".To use the integration you should only consume actions from the "IS" module and not from the "DRV" module, even though the "DRV" exposes public actions.This is even explicitly documented in Integration Builder.2) The Forge component "Human Readable Change History" contains two modules: an extension AutoEntityDiff and a module DiffEntityDataToText.Although of the extension AutoEntityDiff  exposes public actions they are only meant to be consumed by the module DiffEntityDataToText which in fact implements the intended functionality, but by mistake any developer can consume directly from the extension.For the possibility of modules being moved from one application to another application, consumer modules would become with outdated dependencies and when republished they would be broken if they consumed public elements from an Internal/Private module that did not belong to its application.--Tiago Bernardo