Skip to main content

Idea pipeline (top 25)

Filter by idea status

Filter by product

2004 Ideas

kenterweemeThinkwiser

SF - Improved overview for assigning upgrade scripts to specific source model versionOpen

Story:As a SF developer I want it to be easier to assign upgrade scripts to my upgrade. The system should tell me what my source- and target model version is and display any available upgrade scripts for the timeframe I am in. Additionally, I want the system to suggest upgrade script assignments to me if there have been other script assignments with intermediate upgrades.Problem:When developing in branches and in DTAP environments, the Dev environment (nearly) always has a different release cycle than Test, Acc, and Prod. The Develop branch/environment receives way more intermediate upgrades before the model version is merged back to Release, or Main. With these intermediate upgrades sometimes upgrade scripts are required (usually for more advanced data migration).Currently, the SF allows the developers to add an upgrade script for all upcoming upgrades, or to one specific upgrade (from-model version X, to-model version Y). These data migration scripts are usually only required once, so adding to a specific version is the most logical thing to do, but this functionality is hidden very deep in the menu, requires multiple steps and screens and is therefore not user-friendly.However, when later upgrading the Test environment with the Release branch, you want the upgrade script to be run again. The problem is that this is a different upgrade (the from-model version is older, and the to-model version is newer) and thus the assignment of the data migration upgrade script is not accounted for, and skipped. This problem re-occurs with an even larger time gap when upgrading the Production environment using the Main branch.If not paying close attention to what is happening, or triple checking all from- and to-model versions and script assignments, the data can become a mess or even corrupt and the only way to solve that is by restoring a backup of your database after the upgrade has failed.Possible solution:Add an additional detail tab to the data migration screen, that shows all assigned upgrade scripts to intermediate model versions, and allows the user to include, exclude, or modify the upgrade scripts (or deeplink to functionality to edit). So that it is clear what scripts are included in your currently generated application upgrade. This creates a much more user-friendly way in managing your upgrade scripts and prevents accidental (un)assignments that can have unwanted consequences.  

Michael
Thinkwiser
MichaelThinkwiser

Model custom API endpointsOpen

To simplify the creation of custom endpoints in the software factory, I have the following idea:Imagine how convenient it would be to model endpoints easily.For example, suppose you want to provide an interface to your CRM application for third-party tools. To achieve this, you need a way to view and manage certain entities like relationships and customers within the system.Let’s consider a /customer endpoint where we can perform a few operations:GET → Retrieve a list of customers, with an option to pass a customer_id as a query string. PUT → Add a new customer. DELETE → Remove a customer. UPDATE → Modify a customer's details.The GET operation would return a text in the body of the response with a 200 HTTP status code. For this, I propose creating a procedure that takes customer_id as a parameter. (Side note: I am aware that query strings are not type-casted. Therefore, if a customer_id is provided, the service layer should validate whether it can be cast to the appropriate data type, in this case, an integer.)GET ExampleHere is a pseudo-code example for the endpoint:create procedure dbo.api_get_customer( @qs_customer_id int -- QS stands for QueryString, explanation follows in the PUT section. ,@request_body nvarchar(max) ,@request_header nvarchar(max) ,@response_code int output ,@response_body nvarchar(max) output ,@response_header nvarchar(max) output)asbegin set @response_code = 200 set @response_body = 'Lorem Ipsum is simply dummy text of the printing'end  You can output the body in JSON, XML, or any preferred format.PUT ExampleFor PUT operations, it would be helpful to specify that the endpoint expects a multipart form, which can be interpreted as variables in the subroutine.To achieve this, you would define the parameters/fields expected in the form along with their data types. For example, we could expect a name as a varchar and logo_photo as a varbinary.create procedure dbo.api_put_customer( @mf_name varchar(255) -- Specified through the domain system in the software factory ,@mf_logo varbinary(max) ,@request_body nvarchar(max) ,@request_header nvarchar(max) ,@response_code int output ,@response_body nvarchar(max) output ,@response_header nvarchar(max) output)asbegin set @response_code = 200 set @response_body = 'Lorem Ipsum is simply dummy text of the printing'endPAT TokensTo integrate this concept, we can enable the created interfaces in the PAT (Personal Access Token) list. We could add a checkbox to specify which methods should be available through the PAT system. Swagger UITo facilitate developers interfacing with the newly created endpoints, we could provide two versions of the OpenAPI/metadata specification: one with the endpoints and another with universal endpoints. This would allow for straightforward integration with Swagger UI. What does this solve?Well currently you can make open api’s via processflows. But you need to model a processflow, then create a process procedure that handles the calls. And You need to think of everything to for example receive data as multipart forms, querystring data you need to split out of the routings e.t.c. It normally takes allot of code to make a simple webservice/api endpoint. 

Barcode scanning without needing focus to a fieldOpen

ContextBarcode scanner devices basically work as a normal keyboard attached to a phone, meaning it needs focus at some place on the screen where to put the scanned barcode. With barcode scanners with a touchscreen, it is very easy to unintentional lose the focus on the barcode field (even when there is only one editable task field and a default that sets @cursor_to_col_id), which will insert the barcode in the wrong field or not at all. For production/warehouse workers, this is simply not workable since scanning a barcode should just work without having to even look at the screen.IdeaWith this idea I would like a solution to make a fail-proof barcode scanner with the universal GUI which isn't limited to requiring focus on a specific field. In fact it should be optional to even show the barcode field to the user, since most times a barcode doesn't say much to the user.Possible solutionA possible solution could be a setting at a tab-task. When a screen with that tab-task is opened in the Universal GUI, it will catch keyboard input and execute the task with the scanned input in the first parameter with a barcode domain. When there are more editable fields in the task, the task should not execute directly but open (with the barcode field filled in) so that the user can give input for the other parameters. Side notesImportant for this solution to be viable, is that it would always catch the keyboard input when the screen is opened. So even when the focus is on a different part of the screen, like a detail window or the breadcrum/title bar.It should also distinguish the on-screen keyboard/normal keyboard from the barcode scanner input (with a prefix or time-based). Quick and dirtyAs a quick and dirty solution, would it be possible to add a custom javascript event listener that catches the keyboard input, distinguishes barcode input and calls Indicium to insert a record or execute a tab-task? Something similar as @Jasper wrote here: Upload multiple files using the Universal GUI | Thinkwise Community (thinkwisesoftware.com).

Make table variants user selectable like screen-type / grid variant / graph variant.Merged

I was looking on ways to organize a main subject in an application and this is one of the ideas I got. I will make another Idea for the other option.Business case 1;We have a table with a lot of columns. It would be handy for the user to have a number of predefined sets of columns / views when using the system in different scenarios. Switching on and of columns one by one as is possible now is not really handy with the amount of columns. This is one way to realize this.Business case 2;I don’t find the current option to select the screen type handy as it allows to select default screen types which might not make sense for the application and storing it in the user profile makes that a user could “get lost”, not remembering that he or she is looking at something else then other users. The option also doesn’t allow to configure what screen type is handy where, and where it should be allowed or not.Idea;I think that this idea would improve both, giving the developer the option to create a number of preconfigured configurations, which can involve a large number of settings, including the grid layout and the selected screen type.The developer can make a number of variants “available for user selection”. ( Best specific for “Main view”, “Detail view”, … etc. )   The configuration in IAM gets a setting to allow this option for the user or not and this could be extended to a per subject / variant setting, so that it is possible to configure where the option is available.   The user gets an option; “select variant” in the menu.   And … the developer could get the option to show the different variants the way variants of Pivot tables and Graphs are currently shown to the user. ( Making the variant toggle more prominently visible, and faster to use ).I think that this would be a very handy and flexible addition, giving more control to the developer who is developing the interface, and a really fast switch between different variants designed for different use cases to the user.  ( The selection doesn’t need to be stored in the user profile, as it is only one click, that way the user can’t get lost).