Currently, OutSystems Service Studio does not support changing: The editor font family and font size in the Service Studio interface (Toolbox, Widget Tree, Properties panel, etc.) The overall UI scaling for high-resolution displays The language of the Service Studio interface (menus, property labels, and tooltips remain in English) While we can fully style our application UI, we cannot customize how the Service Studio development environment itself looks or behaves in terms of text visibility and localization. Most leading IDEs (like VS Code, Eclipse, IntelliJ, Android Studio) support: Font and UI customization Localization of interface into various languages By enabling these in Service Studio, OutSystems becomes more developer-friendly, more inclusive and better suited for international markets It would create more impact like Increased developer productivity and satisfaction Compliance with accessibility standards Easier onboarding of non-English speaking teams

Scheduled deployment is a smarter, more efficient alternative to manually clicking the deploy button. By automating and scheduling deployments, organizations can improve consistency, reduce errors, and optimize resource usage. Adopting scheduled deployment as part of a robust CI/CD pipeline ensures smoother, more reliable software releases, ultimately leading to better operational efficiency and user experience. Benefits of Scheduled Deployment 1. Reduces Human Error Manual deployments rely on human intervention, increasing the risk of mistakes, such as deploying the wrong version or skipping a critical step. Scheduled deployment eliminates this risk by automating the process. 2. Ensures Consistency and Reliability With manual deployment, inconsistencies can arise due to variations in execution. Scheduled deployments follow the same automated process every time, ensuring reliability across different releases. 3. Optimized for Off-Peak Hours By scheduling deployments during low-traffic periods (e.g., midnight or early morning), teams can minimize disruptions to users and reduce the risk of downtime. 4. Frees Up Developer and Operations Teams Developers and DevOps engineers no longer need to be present at odd hours to manually deploy updates. Instead, they can focus on more critical tasks while the deployment occurs automatically. 5. Enables Continuous Deployment (CD) Scheduled deployment is a key component of Continuous Deployment (CD), allowing teams to release updates frequently without manual intervention. This results in faster iteration cycles and quicker time-to-market for new features. 6. Supports Rollback and Disaster Recovery With automated deployment, rollback strategies can be implemented to quickly revert changes in case of failure. This ensures better disaster recovery and system stability.

Css makes wonderfull things but its not easy to work with when we whant to change something, changing a litle color can make us whant to kill someone, by integranting sass-lang on service studio we can get more power managing our css. check out more info on https://sass-lang.com/

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

 An italian hospital ran out of valves and a company 3d printed the valves: https://www.3dprintingmedia.network/covid-19-3d-printed-valve-for-reanimation-device/My proposal is an app to crowd-source this kind of effort:- Administrators are responsible for registering and validating the registration of legitimate entities with legitimate needs- Entities make requests- The public provides solutionsThis can be implemented by a small team in a very short time and can help save lives.Most people want to help and don't know how, let's give people that chance to contribute.

In ODC - we should have the option to add a folder to app applications into it. Then when deploying you just select that folder with the multiple applications in it and that folder will then queue each application one by one to deploy. If there are warnings or errors on the deployment then it should warn the user. But the whole process of deploying single applications at a time is not very friendly. I do not think that by having the folder you will change the architecture. It is just automating a process

It would be great to have a visual feedback when we have dependencies to update or even when they are outdated and need some action to validate and update them.A preview of what could be to help us.This could be validated when opening the module (as it is already being done) but it would give a visual feedback even when we don't have breaking dependencies. It could also be checked after publishing for example.As this would only validate the used dependencies, probably wouldn't take as much time/effort like when we open the popup itself.

I think "For Each" elements should behave the same as "If" elements in regard to its label.When the Label parameter is blank, its Record List should be shown instead.Here's what a For Each with no label currently looks like. Caveat: when reading through the code, I have no clue which list the For Each is iterating until I click it.Here's what it should look like in this example above. Much better:  I can read which list the For Each iterates without having to click it!

A module in Service Studio will register a "change" when viewing data from an entity in some contexts, requiring the developer to either re-publish or to click "Don't Save" when closing the module: If a developer is only viewing data, no changes have really been made, right? I would prefer not to have to click this "Don't Save" button. Below are the different contexts I tested and whether a "change" occurred as a result. Option 1: "View Data" on a static entity on element defined in the module Result: no "change" Option 2: "View or Edit Data" on a regular entity on element defined in the module Result: no "change" Option 3: "View Data" on a static entity that is being consumed from another module Result: a "change" occurs Option 4: "View Data" on a regular entity that is being consumed from another module Result: a "change" occurs

I'm not sure if there is already an existing idea like this, the search didn't provide me with a match so I'm creating one...We have the ability to import a swagger 2.0 rest services already, but unlike its SOAP counterpart we lack the ability to do this locally from a fileThis should be added IMHOBest regards,PC