Today when we want to make a change in the name of a form, we do not have any direct way from the UI. It leads to cloning the form with the same structure.
Change in the form leads to following issues:
1.Requires change in Groovy
2.Will act like a complete new form (clone) and the old form will still be present, also causing issues while reporting.
3. Requires change in display control
- Requires change in Groovy
- The form can pass to Groovy a list of operations to perform, so that form name is not required by Groovy to determine if we need to run a script on it or not (This will ensure Backward compatibility with existing implementations).
- Have a post save js script hook, similar to form conditions to handle this. (For newer implementations)
- Will act like a complete new form (clone) and the old form will still be present, also causing issues while reporting.
- No way to rename a form because we use the form name as key throughout the ecosystem, can we use form uuid instead for the following:
- Form name and its translations file
- Obs form namespace path
- Have a way to give a new name to a file:
Have form name transaltions.
Requires change in display control
Use the form name, which should not be allowed to change
Note: Today when we have special character in form name we replace it with underscore for the form file name, this is not an extensible solution when all characters in the form name end up being special characters (eg. bengali)
Using UUID to identify the form instead of Form Name seems like an good solution. Ideally, the form should be identified by some unique ID and the name should just be another property of the form like the fields in the form.
If you are planning to use form UUID instead of form name, you must also provide some way to migrate the existing database entries.
@pramidat yes, we are trying to figure out how we can have backward compatibility will update it here once we have solution(s).
Generally we are thinking to have code supporting both and not migrate existing data, as that might be risky.
Thank you @snehabagri for looking into this.
Would it be possible to map out the suggested options into a high level architecture diagram?
I think we discussed pros and cons of using UUID. “Name” is intuitive in my opinion and “UUID” is not suitable for versions (unless you want to create another model to store the form version histories).
UUID must not be only way to do things. You can pass additional information to the groovy script if you want. We also discussed that “OnSave()” method on the form would be preferrable rather to make special provision for Groovy script. Groovy script is a generic approach for “observation” save, and we should not be assuming that “Forms” are the only to save observation (i.e assume form namespace) is always there!
Details for introducing onSave method:
We will have a property under control properties called ‘Save Event’, (similar to form event). Click on this, would open an editor similar to form event we will be able to enter the save event here. (Mock attached)
When the form is saved, the save event will be stored in the form json “events” tag, with a tag called “onFormSave”.
The onFormSave method will be called when the form save button is clicked on consultation, the output from the onFormSave method will be used to ,make the actual save api call.
@angshuonline @sowmika @binduak @vmalini @mksrom @praveenad
We are making following changes as discussed:
- Form UUID to be used as filename for form json file.
- From UUID to be used as filename for translation json file.
- Form UUID is unique for a form name and version
- No change will be made to other parts of the system eg form field path etc.
Please let us know if you have inputs @angshuonline @binduak @kirity.
Please keep in backward compatible. If a file name by UUID is found, look by the name.
Yes, we will keep it backward compatible. Thanks.