In the Universal GUI there is a build-in animation in the form edit-mode: A label of an empty field has a bigger font and is positioned more in the center, when you click on the field the label becomes smaller and moves to the top (see example images below). The same thing happens for lookup-fields when starting the edit-mode. The GUI seems to start the lookup fields empty field and put in the values a little bit later which seem to trigger the animation. Our users find the animation distracting and sometimes even confusing for distinguishing the label from a value. Thus we would like to turn off the animation so that empty field labels have the same position/size as non-empty fields.(How) would this be possible? Unit field is empty (label is big and centered)Unit field is selected (label is small and at the top)
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
In SF 2023.1, after completing a merge session that had a conflict on a control procedure template, the control procedure of the template that had the conflict will not get the status ‘Ready for review’ from the merge session. This results in developers not knowing which control procedures should be reviewed after a merge.When a developer manually puts the control procedure on status ‘Ready for review’, the resolved conflict from the merge is marked as a change however.Expected result: Completing a merge session should put all control procedures of templates with resolved conflict automatically on status ‘Ready for review’. I remember this worked in prior SF versions.
It seems that the Software Factory doesn't handle deleted objects well in branches that are kept open after merging (tested in SF 2023.1). This is demonstrated with the following scenario:Create branch DEVELOP (from MAIN) Add column X in branch DEVELOP Merge DEVELOP back to MAIN and keep the branch open Delete column X in branch DEVELOP Merge DEVELOP back to MAINThe result in the MAIN with this scenario is that column X still exists in the MAIN after step 5. We assume at step 5 the SF makes a delta from the starting point of the branch with the current state of the MAIN and the current state of the branch and determines that column X was added in the MAIN after creating the branch. However, this is not the result that we want/expect (Column X should not exist in the MAIN after step 5).When the scenario is changed to:Create branch DEVELOP (from MAIN) Add column X in branch DEVELOP Merge DEVELOP back to MAIN (make the branch inactive) Create branch DEVELOP_2 from MAIN Delete column X in
When maintaining multiple instances of one application (for different companies), the value of automating the upgrade proces increases but it also becomes more complexe, especially if there are many different project versions within the project. With the current possibilities of the Software Factory it is a pain to create an upgrade package of a cumulative upgrade (multiple versions). The only proper way is to create an incremental upgrade script for each version to the next version so the dataconversion is always applied at right state of the model (as was stated here). But to create suchs a package, you need to generate all code for each version one by one and then you can combine all the 020 scripts (because for the other code files you only need the ones of the latest version). To make this process more simple and to reduce manual steps, an improvement could be that when generating code from version 1.00 to version 1.30, you could mark an 'incremental upgrade' checkbox so that the
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.