The current implementation of the available AWS Forge components from the OutSystems Platform Team only supports IAM user account credentials (Access Key and Secret Access Key) aka Basic AWS Credentials.With a growing consumption of AWS Services in OutSystems applications this can lead to either having to maintain (rotating keys asf) multiple IAM User account credentials or to an overpowered (in regard to permissions) single IAM user account. The AWS Forge Components developed and supported by OutSystems should support Temporary Credentials (Session Credentials) besides the now available Basic AWS Credentials . This will allow to use assumed role credentials. Using roles instead of dedicated IAM user account credentials is also recommended by AWS as best practice.The changes are very minimal as this would only mean adding an additional Property to the extension SessionToken and dependant on if it is set or not either use BasicAWSCredentials oder SessionAWSCredentials. Here is a snippet from our own custom integrationsinternal static AWSCredentials GetCredentials(string acccessKey, string secretKey, string sessionToken = "")        {            if (string.IsNullOrEmpty(sessionToken))                return new BasicAWSCredentials(acccessKey, secretKey);            else                return new SessionAWSCredentials(acccessKey, secretKey, sessionToken);        }Thank you,Stefan

For Traditional Web the "Convert to aggregate to SQL" feature was introduced last year.It would be nice if this would also be implemented for Reactive Web, where the aggregate is then converted into a Data Action, which then has the Advanced SQL inside it. The mapping of the SQL output to the Data Action output should all be part of this conversion function.

Hi everyone,I am currently working on some client/server side validations, and noticed that the Client/Server separation often requires a duplication of code (validations in client side and validations in server side). Because of this, I thought of the idea of potentially having some "Flexible", "Elementary" or "Basic" Action types that could be reused on both Client and Server Actions, considering that OutSystems uses its own set of basic data types that are shared between client and server side logic.The constraint of these types of actions would be:When they are called within a Client Action, they run as Client Action (client-side logic, runs in the browser); when they are called within a Server Action, they run as a Server Action (server-side logic, runs in the server).They cannot contain calls to Client or Server Actions. They can only call other "Flexible" actions in their flow and basic operations that are already available both in Client/Server Actions, such as: If, Assign, For Each, etc.They would generally be used for primitive operations: basic arithmetic and logic operators, and built in List-related actions, restricting any functionality that might make the "Flexible" behavior technically impossible.I understand that Server Actions can be used normally within Client Actions, however (as far as I am aware), they require a server call and therefore cannot be used as validations that run exclusively in the browser.In general, these could be useful wherever a shared foundation codebase between client-side and server-side logic would be useful, such that it could also be extended on both sides independently. The first scenario I can think about is client and server side validations, but I am sure there are similar scenarios where such a functionality would be useful to avoid code duplication.

Create a dashboard in OutSystems that responds to voice commands using the browser-based Web Speech API or other third party voice libraries to control UI navigation, form inputs or logic actions.

I want to have Entities that hide attributes when consumed This way, it will not be necessary to create Structures to do it. For instance, If I have an Entity: When consumed under Expose Read Only, what we see is: What I'm proposing is to be possible to hide some fields, so if we want to hide some attributes, such as auditing or others, we would have: By setting attributes as not Public Therefore, all attributes that were not public, when changing the Entity, would either remain with the original value or would be changed in the environment that exposes the entity. In this way, I see gains, in terms of Consistency and Maintenance, over Structures.

After some years of development, the OutSystems database that supports a DEV environment have a lot of unused tables, attributes, system data, and also the process to remove  the unused espaces doesn't shrink the CLOB's data (ORACLE) and neither remove the spaces that are producers to another unused espaces. Regarding the CLOB's, it's necessary to execute a manual process to shrink the tablespace. To maintain the database healthy and tuned, I think that a processes to housekeeping the database will be a nice to have on OutSystems Platform. Regards, Pedro Matias

Hi there.In order to respect the architecture principles defined by OutSystems, it is recommended that developers install the Discovery application. The application is extremely useful and very necessary, but is only used to validate the architecture and it has about 50 application objects...I believe that applications such as this should should not be considered in the Application Objects count, for licensing purposes.Best regards,Maria

Hi Outsystems Team, Automatically save users’ form data (in localStorage or database), and let them resume filling the form later. This feature ensures users don't lose their progress, allowing them to continue filling out a form from where they left off, even across different sessions or devices.

Outsystems Platform 8.0.1 uses Font Awesome 4.0.2 for the Richwidgets Icon Widget.Font Awesome 4.1.0 was recently released and include 71 new icons:https://fortawesome.github.io/Font-Awesome/whats-new/Some of them, like the new file format icons are really useful.Like jQuery, this type of scripts\fonts\etc, need more frequent updates..

create new tool allow developer to display visual Producers / Consumers for application and modules