Skip to main content

Idea pipeline (top 25)

Filter by idea status

Filter by product

1967 Ideas

Execute all (program objects) improvement to reduce actions/waitingMerged

When I make a small change in a code template and I want to execute that directly to test it (which is something that a developer does a lot in the SF!), I first have to press the ‘Generate control procedure’ button before I can press ‘Execute all program objects’  at the Deploy tab (SF 2024.1). Since ‘Generate control procedure’ is executed as a job by Indicium, I have to wait up to 5 seconds before it is starting and I can press the execute all button.My suggestion is that it becomes possible to execute the ‘Execute all program objects’ task when the control procedure hasn't generated yet and that the task automatically generates the controle procedure when needed upon starting. This way I don't have to wait on the generating job and I even have to press one button less each time.A second improvement would be that the ‘Execute all program objects’ task also becomes available directly on the Functionality screen (control_proc) so that you can select multiple control procedures and execute them all at once. This would be particularly useful in the use case when a new expression field (or task parameter) is added to a table and you want to execute the context, default, layout and handler so that the new parameter is added to them (Note: I don't want to execute the full creation proces for each simple change because that takes too much time, but I do want to see the effect of it working directly).  

Hide columns in a list through a conditionOpen

IntroductionWith a layout procedure it is easily possible to hide a field in a form based on a condition. However when you want to hide a field in the list, this becomes quite tedious.Use casesFor example when you have a a strong entity and a weak entity. Based on a value of the strong entity you want to hide a field in the list of the weak entity. Or in a multi-tenant system, based on a settings table you want to hide certain fields for the tenant. Current work-aroundCurrently you will need to create and maintain a variant with the field hidden, create an extra reference for the variant and place the condition in a context procedure to determine which variant should be shown. This becomes even more tedious when you want to hide multiple fields based on different conditions because you will need to multiply the variants to make each combination possible (and thus having to maintain all the variants with new development).SuggestionTo make this a lot easier and reduce maintenance I would like to suggest to be able to model hidden fields as a detail of a reference in the SF. In this detail screen a developer should be able to add fields of the target table of the reference that the developer wants to hide. For each field a condition should be added when the field needs to be hidden.Based on this data the Software factory should be able to generate the variant(s) of the target table (based on the variant of the reference), generate the extra references and create a context procedure based on the condition of each field. Or maybe the GUI could even hide the fields based on this data without having to create variants/references.