Skip to main content

Idea pipeline (top 25)

Filter by idea status

Filter by product

1967 Ideas

Ionut
Warrior
IonutWarrior

Error on domain input constraintsCompleted

Hi!We've encountered a problem on a task where:We created a task parameter with a domain (note that the name of the task parameter and the name of the domain name are different) On the domain we've setted an input constraint where initially we used the task parameter name, once this was done, the functionality was working good. We've runned the smoke tests, there we saw that the smoke test for that constraint was failing because we used the task parameter name instead of the domain name. We solved the smoke test by using the domain name, but after that we spent almost 3 hours to identify why we got an unknown error on Universal, to discover in the end that it was from this input constraint.Basically, the suggestion is to specify more clear somehow that the column/task parameter name should be the same as the domain name or to identify correctly it even if there are different names, but I will go with the 2nd variant since it will not force the user to create a domain with the same constrains for different columns.The second suggestion is to do something to show more clear where an error is coming from, you get that "Unknown error" and you don't know where to look if is not very straight forward or you didn't worked on the functionality recently. Yes, you can look on the console log messages and somehow by the endpoint to guess what to do or check the GUI, but for example in this case, the functionality was working good on GUI and we got no error there. I really think we can improve on showing more informations when an error occur. 

Set prefilter group mandatory on/off per table variantOpen

We have several tables with variants. Because a table variant can't have its own set of prefilters they all need to be defined in the default table. This means that when a prefilter in the default isn't relevant for a table variant it's ususally set to “off hidden” inside this variant. All good. However in some cases there's another variant of the same default where these prefilters are not only needed but also mandatory. Then the prefilter group needs to be set to mandatory in the default. However in that case all variants where all the prefilters inside the now mandatory group were set to “off hidden” before stop loading in the Windows GUI (and possibly Universal too). This makes sense because having only disabled prefilters inside a mandatory group is contradictory.Because each variant has its own purpose we still want to be able to set a prefilter group mandatory for a specific table variant. The proposal is to make it possible to uncheck the mandatory tickbox in de default table and then make the same checkbox available inside variants. Then each variant can have its own prefilter on/off and group mandatory on/off combination.As a sidenote: perhaps it should be made impossible to set a prefilter group to mandatory when all prefilters inside are switched off. And when a group is marked mandatory make it impossible to switch off all prefilters. This would prevent contradictory settings in SF and an empty list in the GUI. But the main issue for us is that we would like to be able to mark/unmark groups as mandatory per variant.

Improve User Experience by Hiding Badge When Count is ZeroOpen

 Currently, the system displays a "0" in the badge when there are no actions required. While this is functional, it may not be the most user-friendly approach. Displaying a "0" can be confusing or distracting for users, as it indicates there is nothing to be done but still draws attention to the badge.The following template fills the badge value with the number of validation messages or empty when 0.💡To improve the user experience, I suggest that the badge should be hidden entirely when the count is zero. This would offer several benefits: Cleaner Interface: Hiding the badge when no action is required minimizes visual clutter, resulting in a cleaner, more focused interface. Improved Usability: Users would not need to interpret a "0" in the badge. The absence of a badge clearly communicates that no actions are required, which aligns with user expectations in most modern applications. Consistency: This approach is consistent with common design patterns where badges are typically shown only when there is something actionable, making the interface more intuitive. Proposed behavior:When the count is greater than 0: Display the badge with the number of pending actions. When the count is 0: Hide the badge entirely.--The following template hide the badge value when empty or 0.select @badge_value = iif(count(1) <= 0, null, count(1))Consider adding this option as a configurable setting within the subject settings, similar to existing options like "hide badge" and "interval." This would give users more control over how the badge behaves, allowing them to customize their interface based on their preferences.Implementing this change would streamline the user experience and reduce unnecessary distractions, while giving users more flexibility to adjust the behavior according to their needs.