Propose your fantastic ideas regarding the Thinkwise Platform to our Product Team.
When nodes are filtered using the combi filter, the parent nodes of the matching results should always remain visible. Otherwise, the context of the filtered nodes is lost, making it hard to understand where the results belong within the tree structure.Example and desired behaviour:As an enhancement, we would like to see a model setting that allows developers to control this behavior. For example, an option such as "Show parent nodes when filtering" could be added to the Tree View configuration. When enabled, all parent nodes of matching results would automatically be displayed, preserving the hierarchical context while searching.
We were surprised to discover that the "Default Expanded" setting is available for form fields but not for task parameters.Could this option be added to task parameters as well?
Via the Windows GUI it was possible to create onw prefilters, which were on “by default” (if on at last use, then these were on next time view was opened).Would be fine to have this option available again
Hello!I created this idea as result of this post: Basically, what we suggest is that there should be an option to specify the lookup control for grid filters, we received feedback from users about this and since that can be changed for form/tasks, will be nice to have it also in here.Regarding performance mentioned in the post, one solution can be to have the sort defined and then pick top 100 for example and if you don't have what you want there to still be able to type and search it.
The subtitles for open documents are great (Release notes Thinkwise Platform 2026.2.12 | Thinkwise Community), however there are some exceptions where you want to use the subtitle of the active detail (one level down) instead of the document itself. Most menu items in the SF are a good example for this. For instance in the Functionality screen you don’t want to show the branch name as subtitle, but you want to show the control procedure name. I am guessing this is the reason the subtitles are currently disabled for the SF.Therefor I would like a setting on the subject (+variant) level so that you can mark that subject to use subtitles of the active detail instead of the subject itself.
I would like to request the addition of several core capabilities that are currently missing in the Tree View component:Drag & Drop Add Expand All and Collapse All to (Custom-) Actionbar HTML Tooltip Lazy loading of child nodes to improve performance when working with large hierarchies
When you have a main subject with a detail page, I noticed the GUI executes the following query on each row selection in preparation for loading the detail (GUI & Indicium version 2026.1.15). SELECT t1.[REF-COL1], t1.[REF-COL2]FROM [MAIN-SUBJECT] t1WHERE t1.[PK1] = @p0 AND t1.[PK2] = @p1When you have 4 details, it executes 4 of these queries, even when the reference columns are the same. When this is executed on a table, the cost of this query is insignificant since it can always use the primary key index to retrieve exactly one record. But when the main subject is a view, this could be a different story depending on the view code. Could this behaviour be improved so it doesn’t have to access the main subject so many times? It seems that it should at least be possible to gather all reference columns for all references with one query at once. But it would be even better if it could use the data from when the main subject was loaded itself.
Within the code-review screens there is no way to see what code group the template you’re reviewing belongs to. If you don’t name your procedures something like def_do_this or ctx_do_that then there is no way of knowing what code group the template belongs to. Easy fix is to show that field in the code-review screen.
Our user finds the scrollbar too thin to easily drag with the cursor, especially when doing horizontal scrolling.Of course there are options like using the scroll wheel, but many users aren’t accustomed to horizontal scrolling shortcuts.For people with disabilities it can be especially difficult to get the cursor on narrow spots.The compact/comfortable option currently does not affect scrollbar size.It seems that in browser settings it is not possible to adjust scrollbar size.We could apply custom CSS but (application wide) custom CSS is not preferred.
When opening a menu item multiple times, they all get listed in "Open documents". It would be helpful to see which one you have currently open, especially when having multiple tabs with the same name.Can the active tab be highlighted? For example here, indicate which of the three tabs is the active tab,and maybe even make it possible to choose a display column to show behind the subject name.
Improve quality of merge results by making it easier to track which merge impact item has been checked. I check merge impact before effectuating a merge session. Most natural would be to do that by functional segment, but I tend to do it by type of object: I sort the merge impact by type of object, and then check all records of type kind of object and then turn that type off in the filter. After iterating over all types of object, all impact has been checked. The filter is transient though, so when there’s reason to reset the filter, I lose track. It would be handy to have a tick box available that I can tick after checking a record of impact.
As discussed in topic:Also the users of my clients are requesting for more contrast between the selection and the non selected lines.It would be great if we can have some impact on this. A css solution is also acceptable, not ideal.
During development, we wish it would be possible to make table schema changes directly in the active development database from within the Software Factory. For example, adding, modifying, or removing table indexes without requiring a complete creation routine.This will significantly accelerate the development process.
Having countless of program object types makes it kind of a pain for filtering when dealing with merge conflicts (especially merge sessions with numerous conflicts). Long long list of object typesIn my instance I know a majority from the conflicts originate from Translations. Now I have to manually scroll all the way down to the ‘T’ area and still look around there. Would be nice if I could just type and search instead.
When permissions are added to a role by a developer in a branch, there are 4 types of situations:The object is new for the branch and permission is added to a new role The object is new for the branch and permission is added to an existing role The object existed at the start of the branch and permission is added to a new role The object existed at the start of the branch and permission is added to an existing roleI consider the first 3 situations happy-flow use-cases in which no extra risk is involved because either the role is new or the object is new. The 4th situation is different because the developer has changed permissions of something that already existing without creating it. This is mostly done as an exception when ‘fixing’ permissions that were initially forgotten. The risk for this situation is bigger because maybe the object permission was not forgotten but deliberately left out for that role. Specially for column rights this could be the case. Also a developer who added a new field could use the assign permissions task on table level with the checkbox for all columns, not noticing that there were columns left out previously. Currently it is hard to filter on just the 4th situation. When merging a branch it does give an impact overview of added permissions, but the other 3 situations generate the same type of mutations an thus a lot of noise to go through.For us a quick win with a new prefilter on the merge impact screen that would filter on all types of access rights mutations that are added to existing objects in existing roles would be enough to integrate this in our process. Of course a new role review screen would be even better of course.To clarify: with ‘existing’ I mean that it existed when the branch was created.
The parameterized translations is a great tool for making certain fields more understandable for the end-users of the application.Especially with the return of the HELP function in the Universal GUIwe have some great tools to ‘explain the application logic’ to the user. What would be great is when the form-tooltip would be separated from the grid-tooltip, allowing the form-tooltip to be parameterized. (Not showing an ‘ugly’ curly bracket translation in the grid).Why?Hoovering over a field would allow us to explain to the user how a certain value is filled in. Giving room to a explanation with the values of the current row.This would greatly improve the understanding of certain fields for our users, especially ones that are ‘filled in by the application’.It is a step closer to the application than reading a help page or documentation about it, and provides a ‘live’ explanation without having to ‘calculate’ it yourself.For example:We have a couple of fields in a sales order line:currency_id, quantity, quantity_unit, price_per_unit, total_priceIt would be great if the form-tooltip of the total_price could be explained by hoovering over it, allowing us to fill this translation with the following:{quantity} {quantity_unit} * {currency_id} {price_per_unit} = {currency_id}{total_price}As an exampe filling the values currency_id, quantity, quantity_unit, price_per_unit, total_price in as follows:$, 100, PCS, 2.50, 250Would result into a form-tooltip for the ‘Total price ($)’ being filled with 250 as:100 PCS * $2.50 = $250
Currently when adding a field to a table/task or linking a task to a table, the default logic is that the field is added as a input parameter in default/layout/context procedures. As a developer it is possible to disable this, which specially in the case of tab-tasks could lead to performance gain when the task is executed for multiple rows and there is a context procedure for the table that doesn’t do anything with the task.When developing in the SF, you often make small changes that you want to see/test immediately. And when it doesn’t involve any data model changes, you don’t want to wait for the full creation process to finish. However the default/layout/context easily break when a parameter is added, forcing the developer to regenerate each of them again manually. To improve these two points, it would be better if the software factory would automatically detect which parameters are actually being used in the program object and just comment the unused parameters out (leave them commented so a developer could still easily see which parameters are available).The settings under ‘Use concept’ could still be used if there ever is a need for a developer to force it, the options could then be changed to: Automatic (default), on, off.This would improve performance of applications and reduce actions a developer needs to take:🚀 Ideas to be 10X faster - which SF workaround to eliminate? | Thinkwise Community
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.