If it is just a UI requirement there is no need to get rid of the ad-hoc module altogether to achieve this kind of thing.
Hereunder I will take the example of the ‘capture vitals’ that is shipped with the Ref App distro. And I will assume that you are customising the Ref App distro through your own module (read through the end of this post if you don’t have a custom module yet.)
###1) To remove it from the visit actions menu on the Clinician Facing Patient Dashboard:
In the started() method of your module’s activator:
AppFrameworkService service = Context.getService(AppFrameworkService.class);
service.disableExtension("referenceapplication.realTime.vitals");
###2) To remove the default vitals widget from the first column of the Clinician Facing Patient Dashboard:
Still in the started() method of your module’s activator, and still using the same service as above:
service.disableExtension("coreapps.mostRecentVitals.clinicianDashboardFirstColumn");
All these UI customisations are identified by a unique ‘extension ID’. And as you could see here above, the idea is to disable the extension by providing its ID to AppFrameworkService#disableExtension(..).
The one million dollar question is: how to figure out the ID of the visual extension that I want to disable?
Unfortunately that may not be totally straightforward. I would say that there are 3 routes:
- The functionality that you are looking at is coming through a featured module, and that module hooks all sort of new UI components within the Ref App distro upon installing. That’s the Appointment Scheduling UI module’s case, and that’s why uninstalling it just ‘works’ as @sba370 experienced it.
- If it is not brought in by a featured module, then it is very likely brought in by Core Apps. Which, as the name suggests, is a bunch of core UI functionalities. For example, this is where Core Apps brings in the vitals widget on the first column of the dashboard.
- However, and that’s where it is a bit messy, the Ref App module sort of does, sometimes, what one would expect Core Apps to do. It is a bit like: ‘Core Apps brings in the functionality but then it is Ref App that configures it’, so things happens through two modules. For example, this is where the Ref App module brings in the Capture Vitals link in the visit action menu.
By the way, if you don’t have a custom module yet, just uses the Ref App module within the distro. That’s what it is for right in the middle of it: to be the place where to configure the distro the way you want it to look like. Better just fork that module rather than bringing in a brand new module to do so.
Further reading: ‘No extensions listed for built-in forms?’