OutSystems did an awesome job with redesigning the icon system which is used in the Hybrid version of Service Studio.However I think some icon designs got worse, mostly noted the input and output parameter icons:In the old design the arrow in and out are very clearIn the new design:Regards,Daniel

I would love to build my portfolio or a small business using my personal environment in OutSystems, using my domain or having more space to use in the database . I'm not a Champion or MVP, but I believe that the idea would motivate even more OutSystems professionals to reach these desired prominent positions. My idea is that these professionals recognized by OutSystems MVP and Champion can have additional configurations in their personal environments , basic things like: Put your own domain eg: www.soarescorp.com or instead of personal-xasadk Having more than 2GB of database to actually store data. Allow 1 or more 2 developer accounts in personal environment. Only these first two items would be very good, so in summary, my idea is that MVPs or Champions have better functionalities in their personal environments , after all they are promoting the OutSystems brand frequently . Hug, Lucas Soares

Sometimes we launch a deployment, you go back the next day thinking the teams have the new features on the target enviroment and... sorprise! it´s sttoped waiting for confirmation for the impact on running business processes, and loose several hours for the deployment start and finish. Also, if you have two steps, this question it´s asking two times! (if always review on stage 2, please, don´t ask on stage 1). Something than could be ideal for us if you have a parameter to say if you want to ask or not the impact on the running business processes so the LT don´t ask and continue with the deployment (something that works as deployment in two stages, that you can decide in wich enviroments you want to ask or not).

Outsystems don't preserve, by now, session variables in server side, when you call from mobile apps, between calls.This is how it works, and it is "reasonable", but it does preserve some data such as UserId or TenantId (when you do a SwitchTenant) between mobile calls to a server actions for the correct behavior of platform. The problem:If you have a multilingual mobile app, the translations in client side can be resolved with: “ Multilingual Mobile Component ”.But when you have core modules, with server static tables, server process, server sends emails, etc...  What's up with the locale?Currently, the locale, in each call from mobile call is set in the platform default local (for example, en-US). If the user want to retrieve the translation of static tables in his language (for example French), or send emails using the translation resources in french, need to set the locale all the time en each server action that is called by a mobile app.This is also a problem, when you use an aggregate in movile app in screen, and join with an static table, because you can not set locale in server side before aggregate execute, and locale translations allways are retrived in default Platform language. Example:I attach a solution with a mobile app and a core services with an static tables of colors, translated with resources in French, Spanish, and English.We have two server actions, one that returns colors, and the other one that setlocale to french and return colors...We have a mobile app with two buttons, Button "getcolors", that returns the colors without set locale. If you click first, the colors are returned in US (the default locale of platform), and are printed.If you click the second button, locale is setting in french and colors returned in french.If you click second button (and locale is setted), and after you click first button, colors should be returned in french (as the web applications do). But you can see that are returned in english, so locale don't persist between server calls...The second part of mobile screen calle "colors from agregate", is performing an aggregate agains static server table, and, as you can see, retrieves the result in default locale (en-US).This has been explain into support case 2233103, and, we have confirm with Outsystems that there is no workarround once time only, you need to set locale each time you call to a server action. Solution:If you set locale with SetCurrentLocale action in server side, it sounds reasonable that the following calls from this user to servers actions (in that session) you want to use the same language (at least until you make another SetCurrentLocale), so Locale should be also persisted in server side (like tenantId or UserId), between movile calls .

I'd like the posibility to select multiple widgets and then in the properties pane the properties that are not unique to a widget can be edited. For example, when selecting multiple radiobuttons I want to set the destination and style once for all radiobuttons.

With multilingual in a web or mobile project , it is necessary to show dates in the respective languages.The idea would be to have an extra field in the FormatDateTime function that would allow you to receive the location and return the formatted translated date.All the Locales would be expressed according to the RFC 1766 standard format.Examples:In English (default): Friday, 08 november, 2019In Dutch: Vrijdag, 08 november, 2019In French: Vendredi, 08 novembre, 2019In Spanish: Viernes, 08 noviembre, 2019

If we can enable a holiday period for our personal environment, it can save us trouble and inconvenience of having our apps deleted. Thou to ensure this is not being abused, when we set the holiday, there must be a start and end date. And maybe some validations, eg not more than 2 months etc...so that we will not be able to set for 1 year or something. Of course, the time period, will not be able to please everybody. Then after this holiday period ended, the existing control can comes in, eg. if not logged in for 2 weeks, then deactivated and eventually removed Think this is good, as I sometimes do go on a slightly lesser than 1 month holiday, and will not be able to log in.

Hello Guys,It would be great if solution publish process could be enhanced to be faster. Our project has many modules and takes longer than we require in our continuous integration process to publish a solution.Just to give a bit of context with an example - in our daily continuous integration process, we publish a solution against our DEV environment and, if everything goes well, we push it to the next environment for next day QA testing. The issue we face is that with the time it takes, if anything goes wrong with either of these solution publishes, we can have a hard time to react on time to fix the problem and to try again, on the same day.

The new DatePicker  of OutSystems UI, based on flatpickr library, contrary to the old one that is now named DEPRECATED_DatePicker, based in pikaday library, doesn't allow the user to enter a date in the input by typing directly on it  via a widget configuration, which makes it harder to allow that behavior.With this idea I would like to propose to OutSystems that an option is added in the DatePicker_OptionalConfigs structure, an input of the widget, to enable this behavior.The flatpickr library which the new component is based on already allows such a configuration but i's not exposed by the OutSystems UI webblock.Another alternative would be  allowing the developers to extended the widget capabilities by providing an open input (that would receive a JSON) like the old DatePicker used to do. The current approach limits the extensibility of the component and this idea is the only way to improve and extended the component.Below was the approach to enable more functionalities of the underlying library.I understand the expected functionality is possible with the use of a client action that enables the behavior but it requires additional overhead for development. It needs an initialize action for every instance of the component with the required config. With this ideia I challenge the current implementation to improve development experience.Please consider these options and allow the developers to extended the libraries.

Just like Service Studio, it would be great to have an auto-update feature in Integration Studio as well. This would streamline the upgrade process and ensure consistency across tools.