It would be nice to export the entity diagram as an image.

 The ChallengeIn any mass disaster situation (the definition being that the local health structures are overwhelmed and unable to cope with the number of victims) resource management is of paramount importance – and the Covid-19 pandemic no exception. However, it is also necessary to take steps towards rapid intervention before situations quickly deteriorate (it is easier to stop a single ball of snow than it is to stop a full-blown avalanche). The ConceptThis concept is called: Vital Signs Radar – Mobile App.This App aims to help monitor the health status of Covid-19 outpatients (those who are not hospitalized) and articulate with the existing healthcare infrastructures to insure proper case management.The patient has access to a Mobile App that requests certain clinical information be introduced at regular intervals - ex. The patient must answer certain questions: has he taken the medication? Temperature measurements? Other relevant clinical data to be defined. Then the patient is assigned a risk status and a communication protocol implemented.Example – the patient shows no sign of the fever diminishing after X amount of time / or X iterations. The App triggers an alarm and the patient is contacted via phone call or integrated chat by a healthcare professional.The App can also notify the healthcare services to expect a patient whose health is deteriorating and begin immediately to take that into consideration when considering resource management. The ValueRapid Intervention – as soon as the first warning signs appear, the healthcare systems is made aware of this situation. The patient´s treatment can be adjusted before major deterioration occurs.Resource Management – Real time tracking allows for the healthcare system to respond more effectively, knowing what to expect, when and where – and being able to plan accordingly.Real time, traceable data – which will allow for scientists to have a much deeper understanding of the progression of this disease, further down the line. The ObstaclesData Privacy and User Identity – make sure the data being collected belongs to the right person (use credential systems such as in e-banking) and that all clinical confidentiality / data privacy best practices are followed.Digital Literacy – the use of this App requires a moderate amount of digital literacy, that may be outside the grasp of some of the demographics most affected by Covid-10, and that could most benefit from this solution (elderly people). User Experience / User Interface should be a consideration here – as well as some possible alternative solutions (the role of a proxy, or caretaker – a third party responsible for inserting the data). Extension Possibilities / Other ApplicationsThis App can easily be converted into an all-purpose health monitor for chronic patients suffering from various conditions, simply by changing the clinical parameters associated (data the patient has to insert, triggers and alarms) – it could be integrated with video a call functionality with healthcare professionals to discuss symptoms or adjust medication. The medical prescriptions themselves could then be sent via the mobile device and in person appointments scheduled and prepared if necessary.This would allow for better chronic patient care and management – specifically in a time where local healthcare structures are strained and saturated. Technical FeaturesThis solution will be divided in three working areas: the mobile app, the web app and the backoffice web app:Vital Signs Radar mobile app – the mobile app used by the patients and where they add the measurements according to the necessities. The app will also include an alarm feature to remember the patient to introduce the values.Vital Signs Radar web app – web app accessible by medical staff (doctors, nurses, aid health professionals) and where they can access the medical information of each patient that is using the mobile app. Furthermore, this web app also manages the alerts sent by the mobile app by providing them in the platform and by sending alert emails to the person/people responsible for each patient case. The platform will also prepare a webservice so that the information of the patients could be synchronized with other existing software.Backoffice web app – platform only accessible by people with an administrator role and where all the platform’s configurations are set, including:User’s creation and editionMedical information to be asked for each patient/medical conditionUser’s emails to whom the alerts of each patient should be sent to The TeamWe are a team of professionals from the OutSystems partner: Outfit – Tailored Agile Solutions, aiming to give our contribution to mitigate the public health, social and economic impacts and consequences of the Covid-19 crisis in our society in both short and long term. https://www.outsystems.com/partners/PartnerProfile/54622/OutFit/

Given GDPR constraints and consideration, it would be great that Outsystems could support this natively.This could be done in a way that entity attributes could be marked as sensitive data (works for GDPR and other data protection requirements) and additionally set a list of roles that could access them (kind of while list roles, or ACL - Access Control List - roles).Attribute would be presented (or made available) if requesting user has a granted role and if not a specific tag would be presented, e.g. "<protected>" (to distinguish between protected data from empty/null data).Note that attribute would not need to be encryted on the DB, that would easily allow for searches.To sum up, requirement is to rapidly and with low (to none) code be able to restrict access to sensitive data, out of the box.

Hello guys,I was thinking about a large environment, a lot of eSpaces and I realized that manage dependencies it is a little annoying.Think about! We have add a new reference, and we have been typing the eSpace name for searching it,  after it you will pick up your eSpace and then choose your action or you will need search it as well. So, how many times have you doing it just to add a new reference that you just compiled?In fact is, when we add a new reference is very common search an eSpace that we have recently updated, my suggest is add a sub group inside the "manage dependencies pop up" named "Recently  Updated by <me>" like this image.That would help a lot, remember, using the canvas model we are compiling the core and front-end at all times, and when we created a new action in Core we have to make reference.

Consuming eBay's Taxonomy API OpenAPI v2 specification throws errors because recursive data structure are created.FWIW, I have run into this a few times in the past with various swagger specifications.My workaround has been to create an extension and code up what I need using .NET. Given these are usually comprehensive commercial interfaces, this manual coding eats up loads of project time. In some cases this extra and unnecessary coding, testing and maintenance makes OutSystems a bad choice for a project; certainly selling the "low-code" story becomes hard.

The ossys_espace_reference table does not contain the usages of entity actions which is fine for OSUSR tables as long as you have a properly encapsulated code but since there are System entities which are not exposed with read only, it's common to have direct usages of the entity actions which are not findable. (ex.: entity action CreateOrUpdateUser of entity User produced by module ServiceCenter).So my suggestion is for Outsystems to please add these references to the ossys_espace_reference table or on a future platform server version rollout expose the system entities with read only and replace all consumptions by new server actions which encapsulate them.Thanks in advance

Case Management Framework allows applications to extend itself by registering cases, statuses, etc via a public API (BootstrapCaseConfiguration). However, this API is not type-safe and requires converting from a static entity identifier to an entity identifier.For example, in the following image a ClaimsConfiguration static entity is setup with the case configuration:Then to configure the Case, we have to retrieve the static record, and populate the SetupData structure based on it. However the SetupData structure requires a CaseDefinitionId which is incompatible with the static entity:The proposed "fix" is to use TextToIdentifier() which is not type-safe either.Case Management Framework is just an example, but there are plenty of other needs in similar generic components. For example, a component that audits applicational events (e.g. payment failed, checkout completed, login, logout, etc) would have the events defined in a static entity at the application level, but would also define a generic API to audit those events. There's interest in making this component generic (foundational layer) but allowing it to be extended at each application with specific events to each application. This cannot be done currently in a type-safe manner.Advantages of having type-safety would be reducing the human error, promoting the creation of generic components, and also helping the developer to select a correct value by suggesting type-compatible options like highlighted in the mockup below:I wrote a 2-part article about this very same topic, part 2 is more relevant to this discussion: https://leonardo-monteiro-fernandes.medium.com/extending-static-entities-part-2-6f519b639982In the article I discussed the need and proposed a solution to it, but my proposed solution has been broken by OutSystems on release 11.12 and we cannot use it anymore.Regardless of the solution and proposed approach, the need still exists and an example of that is Case Management Framework itself, which would benefit from type-safety.

Integrate Oauth 2.0 as a feature. Oauth 2.0 has become the API authentication standard. While their are options to extend this functionality they are not super simple to integrate and using things like OKTA for a lot of companies gets expensive. OutSystems could aggregate this functionality into a standard function that just gets configured and allow clients to set this up from their own Service Studio/Service Center. This might be a challenge for On-Prem clients, but seems very feasible for cloud based clients. It might even be something that you charge for or use as a value add to drive clients to your cloud instead of On-Prem hosting.

Currently, the ability to easily copy the displayed value of a cell is inconsistently available within the SQL visualizers. While it may exist in specific modes (e.g., entity creation/edit), this basic copy functionality (via right-click "Copy" or Ctrl+C) is absent in other crucial areas, such as read-only aggregate views and the data view of the Advanced SQL Editor. This inconsistency hinders user productivity. The expectation, similar to standard spreadsheet software like Excel, is that users should be able to readily copy the visible content of any cell displayed, regardless of the view's editability. Therefore, I hereby request the implementation of a universal cell value copy functionality across all SQL data visualizers. This includes enabling standard copy actions (right-click context menu and/or Ctrl+C when a cell is selected) for the displayed values in all read-only and editable grid-like interfaces within the tool. Implementing this consistent and fundamental feature would significantly enhance user experience and streamline common data interaction tasks throughout the SQL visualization components. Thank you for considering this important improvement. Best regards, and keep up the good work!

Hello,We had the following issue when referencing a new static entity in another module:An error occurred in task 'Loading eSpace with key 'f69c72e7-9af0-41b4-a12c-c17261b8a9f0'':Input string was not in a correct format.Details : System.FormatException: Input string was not in a correct format.at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)Root cause:We had a static entity defined with a field "Value" of type "Integer"The actual value however was set to 0.5, which is no integer valueThe publish of this module containing the static entity went fine. Then we referenced this table in another module. Still no issue so far.However, when publishing the module we referenced the static entity in, we got:An error occurred in task 'Loading eSpace with key 'f69c72e7-9af0-41b4-a12c-c17261b8a9f0'':Input string was not in a correct format.The platform should block the publish of the initial module if the values of a static entity are not in line with the type.The actual error now comes several steps later in the development process making it very hard to find the root cause.