A few months after go live, production users start complaining that they randomly lose their session in a mobile app.The conclusion from your testers is that users are logging out of a reactive web application in their desktop browsers, and 5 minutes later they lose the mobile session."IMPOSSIBLE!" - you say - "Logging out from the browser cannot possibly terminate the mobile session 5 minutes later, that's absurd and unheard of"So you try to investigate it yourself and, sure enough, the tester was right. Logging out from the desktop browser indeed terminates not only the mobile session, but every other session of the user. Oh, you also find out that this is documented and deliberate: "When the end user logs out of an application, all sessions are terminated".You investigate further, and begin to realize that it's impossible to preserve the mobile session after the user has logged out from a browser . It's also impossible for the user to use multiple browsers on different devices , or even multiple browsers on the same device, because any logout action would terminate all sessions in all browsers. This is unexpected behavior that contradicts how the web works.You reconvene with your testers to brainstorm workarounds, but you're not taken seriously: "Surely this very expensive platform and market leader can support an application running on two browsers simultaneously!" All you can do is wish it did...If this scenario has happened to you on any project, please like this idea and share with others. Together we can change how the Logout works, and enable this very basic feature which is having two independent sessions on distinct devices.

Quite often, I am repeating the same set of joins in queries (both normal and advanced), that I would ordinarily put in a view. Think e.g. of a CRM system that regularly needs "all active clients" or an ordering system that needs "all open orders". Of course if you need just that, it's easy to put it in an action, but I often find myself needing the result and join that with some other tables. Unfortunately, for some reason OS does not allow to define database views, which imho is a great gap. Therefore, I'd really like to see support for database views or something similar (e.g. queries you can define on eSpace level and join the result of with another query, but that amounts to the same).

Hi,In Reactive Web Apps I've noticed that when navigating to public screens from other modules the transition is very slow - it shows a blank screen first, then it starts loading the screen and the CSS, causing a Flash of unstyled content.This takes about 2 to 4 seconds, making it a horrible experience.Upon further investigation, I've discovered that OutSystems is treating the navigation as a navigation to a totally different application, loading again all the necessary resources (JS, HTML, CSS). This is very atypical for a Single Page Application.This makes segregating front ends a major trade-off.Can this be improved?Thanks,Tiago

It would be highly beneficial if the Espace_Versions table included an additional column/attribute to store the publish/deployment comment that is currently supported through the recently added deployment comment option. Additionally, exposing the same information through the LifeTime APIs would greatly help customers build custom audit, monitoring, and deployment tracking solutions. This enhancement would provide better traceability of deployments, improve release governance, and help teams understand the intent/context behind each deployment without depending solely on external communication channels or manual documentation. Potential Use Cases: Custom deployment audit dashboards Release traceability and governance Tracking hotfix/business deployment reasons Displaying deployment comments in internal monitoring consoles Easier PROD publishes analysis and reporting Kind Regards, Sandeep

Currently each time a site property is saved, the new value is applied to the factory. This is separately done for each site property value that you adjust. In core modules applying the new setting can take some time. It would be nice if it is possible to change multiple site property values before applying the new settings to the whole environment.

Currently, only Images, Scripts, and (Deployed) Resources expose their runtime path. It would be valuable to extend this property to Stylesheets as well, since they can be considered a resource like any other. Access to this property would give developers greater flexibility in managing the CSS cascade, particularly in more complex scenarios.

Sometimes I do development in my 4K monitor and its hard for me to do development in the studio because everything is small. If the studio has UI Scaling feature then I can scale the studio's UI to make it everything in the studio (texts & buttons) bigger

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.

When compiling or publishing an application, it would be helpful if errors and warnings could be grouped by Screen, Block, or Action.

 Use-case: I have an app with many screens and tons of CSS classes defined in the style sheet; I decide I no longer need one or more screens, so I delete it/them; now, I have a bunch of CSS classes defined in the style sheet that are no longer used anywhere in the app. Problem: I don't want unused CCS classes in the style sheet, so now I'm forced to search for each class in the app to check if it's used or not before safely deleting its definition. Solution: there should be an easy way to "Removed All Unused CSS Definitions", just like there's a "Remove unused elements" (see image), and/or a visual cue on the Style Sheet, next to each unused CSS definition, to make it easy for thee developer to see that that particular definition is not being used (that way the developer can manually delete only the ones they're sure they'll never use again).