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.
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.
It would be good to have native support for PostgreSQL and MySQL
Outsystems Consume REST functionality already interprets underscore casing, to Pascal casing and vice versa - the same should be implemented for Outsystems expose REST functionality.
Most of outsystems developers use pascal casing to build their application; However when an external application and external developer consumes an exposed REST service, the de facto standard naming convention for REST is to be used, that is the underscore naming convention.
Example
ClientId would be Interchangeably interpreted as client_id and vice versa
ThisIsAnExample would be Interchangeably interpreted as this_is_an_example and vice versa
yetAnotherExample would be Interchangeably interpreted as yet_another_example and vice versa
Developers should be able to build their app as they normally would with outsystems platform using Pascal casing naming convention for REST Input/output parameters and JSON request/response structures - and outsystems would be able to convert between pascal/camel casing and underscore casing.
Request:
Developer could enable an option accept "underscore casing" compatibility or outsystems can build this in by default.
Response:
REST response could response back with either Pascal casing or underscore casing (there should be an option to enable this OR at least add a "OnAfterResponse" action to let the developer manipulate the REST service method response.
I have an Aggregate in a Preparation Screen Action that joins to the User Entity several times because there are several User ID Attributes in my principal Entity. Would like to add the User.Name attributes of each user to a List Records widget but there is no quick/easy way to do this. Wouldn't it be nice if you could drag and drop the attributes directly from your Aggregate directly to your Interface? You can already pop-out the Aggregate screen from Service Studio to allow you to see it at the same time as your Interface but drag and drop is not allowed. See screen shot attached.
Recently we identified that one of the developers is able to use the System "Login" action and is using it to get into the environment even as an administrator and is able to access critical components like Users and other applications as admin.
He had done this without any wrong intentions but we from the COE Team here in Schneider feel it can be misused.
Hence we suggest to somehow hide this action from end developers to even see it.
I have raised a support ticket for this. CaseId=2035898
Some Excerpts:
"It will not be possible to go through every warnings or open applications to check if developers are misusing this feature. And above this we from the platform COE will be able to check this when the application is moving from Dev/QA to higher environments like Pre-Prod and Production. We will not validate “on a daily basis” what the developers are doing in the lower environments like Dev and QA.
It is important to understand the Schneider landscape how we use OutSystems. We are from the Platform COE here in Schneider and we are well versed with the platform. But there are many regional teams who are novice in OutSystems and may unknowingly cause mistakes. For the success of OutSystems we have to entertain these set of developers who are joining in huge numbers to this community. OutSystems in Schneider will be a success only if we have this huge vibrating community.
Our belief is the platform should be robust enough to not allow any developer to play with this feature which is allowing any end user to even login to the platform as the platform Administrator. Hence our sincere request is to see how this can be avoided at the platform level."
When assigning a value in the Expression Editor, the Example text in the description had exactly the code I needed. However, when I tried to select any text from the description I was unable to.
I would like for this text to be selectable, so that it can be copied and pasted into the expression editor.
I have a web address that requires a username and password to access the WSDL. (Basic Authentication)
Therefore, I cannot consume the SOAP Web Service directly within OutSystems (Integrations -> SOAP -> Consume SOAP Web Service)
I have to create a local copy of the WSDL and save it locally including EVERY XSD within the WSDL. I then have to manually map the WSDL to the local XSD's.
Then I consume the LOCAL WSDL and all works.
Extremely time consuming for large WSDLs.
We want to use the 'Consume SOAP Web Service' and simply pass in the username and password (optional)
CSS Variables (aka Custom Properties) makes it possible to organize and refactor stylesheets. They are already supported by every major browser, except for Edge, which will add it soon.
You can already use CSS variables in OutSystems applications. But Service Studio doesn't understand them, and the design-time preview will have low fidelity.
With this CSS module, you can declare custom variables, and then use them throughout the stylesheet. For example:
:root { --primary-color: #9E0616; } a { color: var(--primary-color); } /* ... and many other styles could use var(--primary-color) */
In such a stylesheet, changing the primary color requires only changing one line.
This would greatly simplify the instantiation of a theme, because the variable can be declared with a default value on the theme, and when a consumer inherits the theme, it simply overrides the variable value:
/* On the theme (e.g. LisbonTheme stylesheet): */ :root { --primary-color: /* default */ #000; } a { color: var(--primary-color); } /* On the application theme (e.g. MyApp stylesheet): */ :root { --primary-color: #9E0616; }
In an exception handler, it should be possible to re-raise the original exception if it could not be appropriately handled using the same Exception type for processing further down the line.
Currently we have access to the ExceptionMessage but NOT the Exception (type) meaning that if we re-raise the exception we have to choose a type (which we typically don't know). I end up having to create an "UnknownException" type even though the original may have been a standard type so it may not be appropriately caught later down the chain.
Only one option is available to delete the Old eSpace versions by Duration only. Please provide the below option to user to delete the Old eSpaces.
1. eSpace or Extension name
2. Duration
3. Published by
While doing a "full publish" of an application on Service Center If an espace is published by a Service Studio it usually breaks the "full publish". This flag would throw a message in Service Studio letting the developer know that he has to or should wait.
Many times you have warnings on your screen, however you need to go in the TrueChange tab, and look for them visually to solve them, if you have many it gets difficult to find.
My Idea is the option to redirect to the warning through the element itself, or already suggest the resolution in the element itself as the image below.
When we work together as a group. Each publish makes new version.
It would be nice if we can see version even further deep as per screen version.
Would be nice if "Find Usages In All Espaces" didn't check references when it opened other espaces, really slows the workflow down... maybe do it in the background after opening the eSpace? Or on the first publish attempt?
J.Ja
It would be kinda nice if, when two ideas are merged, the e-mail telling folks about it contained a link to the new idea.
You know, so we could actually see it...