Skip to main content

Idea pipeline (top 25)

Filter by idea status

Filter by product

1968 Ideas

Mitigate security risks by evaluating added permissions for existing objects in existing rolesOpen

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.

Xavier de Bondt
Apprentice
Xavier de BondtApprentice

Parameterized form-tooltip translationOpen

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

Make input parameter definitions smarter to reduce the need for regenerationOpen

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