While creating documentation or looking for mistakes done during the creation of the Data entities, it would be useful to have a "Copy context" or "Generate Context from Entity/Entities" that allows the user to have a quick way to look at the structure of the data completely in a useful format like: Entity: Goal Attribute 1: Id (Goal Identifier) Attribute 2: Name (Text, 250 characters, Mandatory) Attribute 3:....

If there are any advance queries, replace that by aggregateDon't use foreach Loop in preparationDon't use if conditions in preparationi.e try to avoid if conditions in aggregateApply pagination on list pageDon't show more than 100 records on single pageMove JavaScript webblocks to bottom of pageDon't use preparation aggregates directly in screen actionsBefore using them in screen actions refresh themSuggested by  Suraj.

The SortRecordList extension allowed to have multiple sort criterias. The ListSort should have feature parity with that extension, at least.Having this built-in on the platform would be useful for sorting third-party datasources. For example, imagine that a web service returns financial transactions, and has two distinct columns: Date and Time. We would need to sort on both columns to be able to present data in chronological order.

While using the Upload widget, it would be really helpful if there were built-in properties to set allowed file types (like .pdf, .jpg, .docx, etc.) and a maximum file size limit (in MB or KB). Right now, we have to write custom logic or JavaScript to validate these things, which takes extra time and can be tricky for less experienced developers. If these options were available directly in the widget, it would save time and make file uploads more secure and user-friendly out of the box.

There should be ability to add unit tests automatically for any actions. Also a unit tests should be automatically added to a Core Modiules.

Hi,My suggestion is that modules could reference a particular version of another module.This would allow teams to keep developing and evolving their modules and not being concerned about apps that are not currently being worked on becoming broken or needing someone to manually update them.This is a very common scenario in larger factories and even with proper architecture it will happen.The way I see this working in practice is tagging module versions as "stable" and any consumer could choose to reference "current version", which would be the same as it is now, or one of the "stable version".This extra concept of "stable version" might be needed otherwise we would always be selecting from a list of hundreds or thousands of versions.From a platform perspective I believe this is quite doable! We can already just clone any module and reference that one (thus creating a kind of stable version), the platform could do this behind the scenes and have that "hidden clone" as the Stable version.The biggest difference from what we can do now is that these clones MUST use the same physical tables of the main module! (as in: not creating new ones)It goes without saying that what I'm suggesting here is also the way most "traditional" languages work!Cheers,Hermínio

I would like to see an accelerator in SS (and ODCS) where we could choose to create a timer based on the below template according to the best practices to ensure Data Integrity, Timeout Prevention, Completeness and Doesn't Repeat Work. One could customize it afterwards to his needs or simply choose the current option to create a timer with an empty canvas. The accelerator should also include a "KillTimer" Site Property in the flow to ensure there's always a way to stop a timer when needed.

I would like to have a sort of a screen in the Service Center where all this information would be centralized and displayed, and where it would be possible to list all APIs and to navigate to the API edit screen from there.It is not the first time where I am in a project where it is used a middleware for APIs management inside the organization. And a problem that always happens when, for some reason, the middleware changes its DNS, so from xyz.whatever to azurexyz.whatever, is that to make the changes in all the currently used APIs I need to go espace by espace (or module by module) in Service Center, assuming that I don't need to go into SS to see where all APIs are located and I don't miss any of them and change one by one.I know it is possible to have this kind of list looking into the system entities, but I believe this should be part of the product because it seems to be commonly necessary.This would also help, in cases like the example, I described above, to make sure that we don't forget any API where the URL basis needed to be changed.

With AI being our right hand and helping us with a lot of the product management/vision, it could be possible to create a standard widget structure in the widget tree from a HTML. Use Case: 1 - Use favourite LLM 2 - Generate mockup (using OSUI as theme for the generation - better results) 3 - Copy HTML 4 - Right click screen in ODC/O11 5 - "Build Widget Tree from HTML" 6 - The screen is populated with a bunch of widgets that respect the html

Currently, the Serialize node only provide an option to exclude attributes that have default values. However, there is no option to explicitly exclude custom-selected attributes. This capability is especially useful for logging scenarios . In many cases, creating an additional Structure just to map and exclude specific attributes is redundant and unnecessary. Most serialized outputs are eventually passed to a JavaScript node , written to logs, or stored in a database purely for logging purposes. Allowing developers to select which attributes should be excluded during serialization would significantly reduce development time, keep the code cleaner, and improve maintainability. It would also eliminate the need for extra mapping structures that add complexity without real value.