My name is Ricardo Gomez, and I work regularly with DHIS2 implementations. At the moment, I am looking to work with custom forms in the new Data Entry app and to migrate existing custom forms to this new app. As there are discussions around re-enabling JavaScript for data entry custom forms, I would like to better understand what the scope of this will be.
Specifically, which JavaScript features are expected to remain disabled or restricted once JavaScript is re-enabled (for example: DOM manipulation, access to DHIS2 internals, external libraries, network requests, event handling, etc.)?
Any pointers to documentation / jira tickets, design decisions, or past discussions would be greatly appreciated. Thanks a lot!
@rgomez, I think you can follow updates on this JIRA ticket for tracking the progress on custom forms. But so far, I think it’s still under development.
As @chingalo mentioned, the best way is to follow the ticket, and this PR for the Legacy Custom forms plugin. The plugin is also published in the alpha channel of the aggregate-data-entry app, so you can go ahead and install it from the App Management and test it while it’s in development.
In short though, the aim of the plugin is to support existing custom forms without modifications, so there are no explicit restrictions. The old forms should work out of the box unless they used hidden internals that were available in the struts app (which they shouldn’t have anyhow). But if they only used methods that were in the public interface in the old form.js (things under dhis2.de namespace) then they should work seamlessly - the plugin provides a shim for these old methods so that they work in the new app in a way transparent to the forms.
If something doesn’t work, then you’re able to update the forms and there are no explicit restrictions on the JavaScript ran under the forms - there might be some implicit restrictions, from adding CSP Headers for example in the newer versions of DHIS2, which would block inline JavaScript, but, again, a simple update to the form should be enough if anything is broken.
In the future, the plan is to add some security restrictions, mainly to restrict API calls outside the domain of the DHIS2 instance, but we will likely introduce these in an opt-in way. We will also have a different modern plugin entry point, that would allow people to build custom forms that are more modern-looking (and secure by default). But this plugin (the Legacy Custom Forms plugin) will remain and its aim to make old forms work with the least amount of friction possible.
We are very close to releasing the plugin to the beta channel and when we do so, we will also add documentation for custom forms authors, and we encourage you - and others in the community - to test it with your own forms and report any issues.