Service Studio SDK with some kind of API that enables programers to develop plugins that generate OutSystems "Code" and extend the IDE

When editing translations in Service Center and defining which strings should be translated and which should not, Text found in Style Classes is also added to this list. Translating CSS adds unnecessary risk and complexity to the application. Ideally Text used in Style Classes is either ignored or default behavior is "Don't Translate". it's generally not a common or recommended practice in web development when working with i10n or l18n. Current list of Text used for translations.

Currently, if you want to integrate with Amazon DynamoDB, a popular NoSQL database service provided by Amazon Web Services (AWS), you would need to use a Forge component called Amazon DynamoDB Connector. This Forge component provides pre-built connectors and actions that simplify the process of integrating OutSystems applications with DynamoDB.Simplified development: With native support, developers wouldn't need to rely on a third-party Forge component. They could directly access DynamoDB functionalities through Integration Studio, reducing the need for additional installation and configuration steps.Enhanced productivity: Native support would provide a seamless development experience within the OutSystems environment. Developers could leverage visual tools, such as drag-and-drop actions and configuration wizards, to quickly build integrations with DynamoDB.Standardization and stability: OutSystems could ensure that the integration with DynamoDB is well-maintained and kept up to date with the latest changes in DynamoDB's APIs. This would provide developers with a more stable and reliable integration option.Easier learning curve: By incorporating DynamoDB integration into Integration Studio, OutSystems could provide documentation, examples, and tutorials specific to DynamoDB, making it easier for developers to learn and utilize the service.

The idea is simple, so we can define events in a webblock and the idea is that when we put the webblock in a screen we need to assign some action to those events and the idea is have the possibility of define the order that those events should run when the screen is rendered. Regards Miguel Grilo

Right now the pattern is to put a hidden link on the screen and use "Widget Click" to trigger it. That's kind of ugly and we have the need often enough that this is a hassle. There should just be an Action to make a popup occur, have it work like the "go to this page" does, but as a popup.

It would be really helpful to have the ability to disable client-side sorting of filter values when those values are set using the SetColumnFilterOptions action. In our case, we have a text column that requires specific sorting logic. We already handle this sorting correctly in SQL, and we need the filter values in the Data Grid UI to respect that same order. However, the grid applies client-side sorting to the filter values, which overrides the SQL-defined order. We were able to work around this by disabling sorting on the valueFilter instance of the column using the following JavaScript: OutSystems.GridAPI.GridManager.GetGridById($parameters.GridId).features.filter._filter.getColumnFilter('Product').valueFilter.sortValues = false; While this works, it’s not ideal: It’s difficult to discover unless you’re already familiar with the Data Grid API. It relies on internal/private APIs, which makes it fragile and not future-proof. It would be great if SetColumnFilterOptions had an input such as DisableSorting (or something similar) that when set to true, it essentially does the same as the JavaScript above, allowing developers to easily preserve server-defined sorting

Add column on TrueChange tab to show the location (web page, action) of the error that is being shown.

When designing a REST API, it would become beneficial for the generated swagger file to include an 'enum' that defines possible values for parameters representing static entity identifiers. Consider the following scenario (see attachment) as an example: Within the REST API method, there exists an input parameter of the Entity1 identifier type. However, the generated swagger file merely denotes this parameter as a string without providing further elucidation. By incorporating an 'enum' into the swagger, additional clarity can be imparted regarding the acceptable values for this parameter. In this instance, the enum would specify: [a, b, c].

When deploying from one environment to another, sometimes there are applications that have dependencies that Lifetime detects and tries to recomplie and redeploy. This is shown in the example below: In this case I have only 1 dependency, but sometimes I have more than 50 and it gets very cumbersome to have to uncheck all (as sometimes I don't want the apps to be recompiled because the change doesn't really affect them and impacts deploy times). So I'm asking for a simple "check all" and "uncheck all" boxes right above the dependency counter. Thank you.

1. Have a 'Yearly' selection Currently, we can select 'Daily, Weekly, Monthly' when we are configuring when timers are suppose to run. It will be a nice to have, if a 'Yearly' selection is available as well. There are some jobs which are only required to run once a year. Currently, we can only build a check, in the logic of the timer, to check whether whether it is a new year before continuing the logic. 2. Have option not to automatically run timer, when it is set from 'Inactive' to 'Active ' We have encountered a situation before, when we need to set the timer to Inactive for debug purposes. As the application is already live in PROD, naturally the status of the timer is Active. Then we found there was a bug, as such, we set the timer to Inactive in PROD, while we are still trying to fix the bug. After fixing and when app was deploy to PROD, we have to switch the timer back to Active. However, once we switch, the timer automatically runs again, even thou it is not the correct time to do so. So our end users panicked, as they know the auto emails, reminders etc, shouldn't be set out during that time of the day. End-users being end-users, they might not understand that we are just trying to fix a bug and then re-activate the timer