When working with Advanced SQL actions, there is the option to add test values to the parameters, and run the query with them. The executed query is shown in the "Executed SQL" tab, which is great. However, it would be very helpfull if that query could be extended with the parameters used. e.g. declare @company_id int; set @company_id = 3; SELECT [OSDEV1].dbo.[OSUSR_WU3_COMPANY].[ID] , [OSDEV1].dbo.[OSUSR_WU3_COMPANY].[NAME] FROM [OSDEV1].dbo.[OSUSR_WU3_COMPANY] WHERE [OSDEV1].dbo.[OSUSR_WU3_COMPANY].[ID] = @company_id That would make it possible to copy the query with the used parameter values, and paste it in the database tool and be able to run it directly (instead of having to configure the parameters again). Please note that this is somewhat related to this idea, but I believe my suggestion is better: https://www.outsystems.com/ideas/8176/show-real-value-on-advanced-query-executed-sql/

Please can you add the ability to apply field descriptions to ODC External Logic components. If there is already a way to do it, it's not in any of the very scant documentation.

Please add the ability to upload a demo app for ODC External Logic components.

Please can you provide an option to use the uploaded Demo as a Try Now option, hosted on the forge server. Currently, if you don't have a corporate account/server you are willing to make publicly available, you have to use you personal account for the Try Now , but that expires and gets deleted every week or so, causing the Try Now to die.

The help page you are given a link to when publishing from ODC to the Forge is completely blank. Can someone add some details please?

As requested by OutSystems Support Team, I am creating this Idea because it's important that the build log for any compilation on mobile on ODC be similiar to what we have in O11. Today, the mobile build is a huge amount of text that can be difficult to understand what is the main reason your mobile app is not compiling. In O11, it's more easy to understand. Maybe on ODC, put the main error on the top (or at the end) of the file so the developer can easily identify the root cause of the APK/IPA being broken upon compilation.

The default behaviour of datetime variables in Reactive apps is to convert from UTC to local time. This is a great in a lot of use cases, but hard to work with if a user want to see data in a different timezone.In this forum question , some 'hacks' are proposed:Use datetimes as textCompensate at server side for the difference in client timezoneThe prefered solution is to let developers set the config for this automatic conversion. The default behaviour to convert is good, but make an option to overwrite the default behaviour.

 New functionality: It would be nice to select some logic nodes, right click and "🔒 lock" them. How it will affect the developer? When you want to do changes, you have to unlock the nodes and provide a comment/reason why you want to change them. Other effects? During the merge or code update, all commented changes are shown so each developer knows something happened there. This would be a good functionality to protect Interface-code or some heavy business logic that normaly does not need to be changed. When would this come into play? Replace All / Find'n'Replace might change code that should only be changed with care APIs/Interfaces might be changed because of a call or so, but more than just one person should be informed about this Law relevant logic might be changed etc.

I the Rest configuration in Service Center should have the same fields that are in Service Studio. When I configure the Authentication in Service Studio appear the field Scopes But in Service Center this field doesn't exist You should have the same fields in both places

One of the purposes of publishing a solution, is to refresh all modules in it, and reflect a change of an upgrade. What I propose, is to remove unused dependencies between the defined modules in the solution. I recommend for it to a configurable option. But it would be helpful especially in big projects, where the architecture is big and complicated. Also, it could be a helpful option before checking the architecture in Discovery. Before the check we have all modules refreshed, and all unnecessary links broken.