Skip to main content

Idea pipeline (top 25)

Filter by idea status

Filter by product

1967 Ideas

Extend custom_display_format functionality to get Excel like field display/edit possibilitiesPlanned

The SF and data domains offer little possibilities to control the presentation of numbers. I thought the custom_display_format extenders would be the solution but I found some shortcomings that make them less useable in practice. I discussed this with Thinkwise people: The current behaviour is as intended but they think the following would be a good improvement.Simple example for a currency datatype NUMERIC(18,3) where users normally want to see only 2 decimals but the extra decimal is needed for calculation accuracy. By using an extender with "€ 0.00" format for the domain you get the following behaviourPositive:Display with 2 decimals is correct and third decimal is used for rounding up/down correctly An entered number with 3 decimals is correctly stored in the underlying tableNegative:When EDITING data there is no way to see the third stored decimal When EDITING it is not possible to edit the existing number; you have to clear the field and reenter the complete numberThe behaviour is the same in grid and form screens. We would expect behaviour like e.g. Excel:Display data using the Extender. They are called custom_display_format for a reason I think. Possibility to edit the exact stored dataWithout this behaviour the introduction of the extender seems of little use; the same could be achieved using an expressions field. But a task would be required to edit data and this is what we want to prevent.An extra improvement would be if the scope of the extender could be specified on a lower level than a domain. Then you would get the possibility to present and edit the same table field in multiple ways; the exact data for the finance department and in another screen rounded numbers for sales but still the possibility to edit the exact number.

Arie V
Community Manager
Arie VCommunity Manager

Ability to hide Domain element based on logicOpen

We often have situations (especially on status fields) were a user is only allowed to use certain element values or to move it from one element to one other element. The availability of a given element would be based on User permissions or current status (for example: if current status is A, you can only change it to B, and if current status is B you can only change to A or C, but not D). The current ways of resolving these situations feel like workarounds, which should not be necessary for such a straightforward request in a platform called low code. Suggested solutions I have heard are:Create two (or more) similar Domains with similar, but not all, Elements and determine in the Layout procedure which one to show. This basically means adding (sort of) duplicate domains, which is ugly and risky from a maintenance perspective... Use a Lookup to a Table or View with Pre-filters. This is more effort, clutters the Data Model and is probably worse in performance than a Domain with Elements...A possible solution that comes to mind is the ability to set in the Layout procedure when to show/hide certain Elements. It would be good enough if somehow the Layout procedure recognizes Domain with Element type of fields and we can write logic on each individual Element within that Domain.  How do you like this idea? If you have other suggestions than the Layout procedure to fix this: let's hear it!

Navigation sidebar - Improve menu-item openingOpen

There are currently 4 ways to open a menu item from the navigation sidebar. User opens a menu-item by CLICK or keyboard-select/ENTER. This opens the menu item in the current browser tab. This is correct behavior (no changes proposed). User opens a menu-item by ALT+CLICK or keyboard-select/ALT+ENTER. This opens the menu item as a new browser window. The following improvements are suggested:The new browser window misses parts of the browser topbar (it shows URL bar only). Improvement: open as a regular browser window. The navigation sidebar is missing in the new browser window. Improvement: open the browser window with the navigation sidebar visible ALT is not the universal browser convention to open links in a new browser window. Change this to SHIFT. User opens a menu-item by CTRL+ALT+CLICK or keyboard-select/CTRL+ALT+ENTER. This opens the menu item as a new browser tab. The following improvements are suggested:The navigation sidebar is missing in the new browser tab. Improvement: open the browser window with the navigation sidebar visible CTRL + ALT is not the universal browser convention to open links in a new browser tab. Change this to CTRL (also: scroll wheel click). User opens a menu-item by SHIFT+CLICK or keyboard-select/SHIFT+ENTER. This opens the menu item as a near-full screen focused pop-up. The following improvement is suggested:SHIFT should not be used for this as that is the universal browser convention to open links in a new browser window. Change this to CTRL +ALT (or another combination that does not interfere with standard browser conventions). Note 1: all above is described from a generic Windows desktop user perspective. Thinkwise to align this to Apple and Android OS’es as needed. Note 2: the browser context menu when right-clicking on a menu-item should also include default options such as ‘Open link in new tab’, ‘Open link in new window’, etc. It currently does not show that.