Right now when a user navigates to a URL that is not associated with a page or the URL for a page that has been removed, you end up at an ugly 404 page located in /customHandlers/ As seen in this forum post you can edit the custom Handler's page directly, but my understanding this would change it for all apps, and doesn't seem possible in a Cloud environment. It would be nice if we at least had the option of configuring the 404 page, similar to the Invalid permissions or Internal error pages. Especially if one of the inputs of this page was the originally attempted URL, meaning we could redirect the users if they were attempting to go to an old screen that was removed, but the content is now elsewhere. Thanks!

ODC Portal should have a screen with a interface to manage all the setting of the OuSystems Cloud connector, instead of a command line.

There could be some magic feature that would make this time saver feature. :-)Then we could make a simple query to build the 'skeleton' of a query and then introduce the aditional rules that cannot be defined in a simple query.

IDEA: Creation of an environment for certified developers (with at least 6 months or 1 year of certification) where he/she could test the advanced skills to pass the professional certification, the management of environment, lifetime, to create plugins or give support to the ones created when had access to such environment, etcThis would solve the lack of practice of many developers who want to give an extra step in the career and don't have opportunity to test in the company where he/she is working and would spend months or years just with theoretical knowledge until have the opportunity to test what have learnt; and for the developers who created a component but no longer have access to the lifetime would be a good chance to update the components.

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 when we are trying to create a new idea for ODC, we get this warning: While I understand why this exists, it removes a key value of the community: visibility, discussion, and voting. If the problem is to ensure that the suggestion goes directly to the ODC team, wouldn't it be better to just notify said team when a new idea is created with the ODC category?

I suggest excluding the static entities from the counting of Application Objects , as saving it leads to spaghetti code, and using it does not indicate the complexity or magnitude of the project.

Hi OS Team, Why don't we have Conversion Assessment Tool for Cloud? I think this will be beneficial for some of the companies who has a Lift and Shift from On-Prem App to Cloud. As currently some of the companies who have On-Prem Setup has issues on installing the Conversion Assessment Tool on their environment.

Today, when there is need to do some configuration in the destination environment of a deployment (site properties, timers, end points, etc), this configuration must be made after the deployment is done.Would be nice to have a way of preparing those configurations during the planning and see them being applied automatically during the deployment.

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.