Add Preview or Edit action for Build-in Apps in Manage Apps

Hello developers (@dev3, @dev4, @dev5),

In Manage Apps app, there is list of app definitions. Built-in apps cannot be edited and they doesn’t have Preview action, so it means that its impossible to copy these apps definitions.

Question: Do we want to add Edit action (just like in Implementation-Defined apps) for Built-In apps or do we just want to add Preview action for them?

Fine with me to have a way for one to view the json of built in apps

@tmarzeion +1 from me too very useful.

Additional questions:

  1. Where is the information from the apps read from - I know its not stored in the database. If not why?

  2. Was any thought put in exposing the apps via webservices.rest - some common configuration parameters?

How about extensions, I know they do not have a screen but the two questions above still apply.

An AppFrameworkFactory is responsible for loading apps from wherever it choses, the default one that ships with the appframework module loads them from the classpath and there is another factory that loads them from the database, this is the one that loads those apps you add via the manage apps page.

I believe the app service can be exposed via rest if necessary, I’m not sure if anybody has put any thought into it though.

From an implementer’s perspective, at the time when we first looked at it we were surprised/annoyed that certain built-in apps would not behave like the others and were locked. So having them being editable is what we would have wished for.

I know we worked around it and from the top of my head I don’t remember anymore how, but I can dig in if that’s of any interest.

This would also be a good time to add some filters:

  1. Enabled or Disabled

  2. App Template type

  3. Not sure if the extensions that the app includes can be added (that can be at a later date)

  4. Source module - over time you get to learn which module provides the app and its easier to filter by this

In addition to making them editable I would add a revert feature, which would restore app’s initial configuration.

@tmarzeion, how about you create separate issues for:

  1. Viewing/editing built-in app’s config
  2. Restoring app’s config
  3. Exposing app’s config via rest
  4. Filtering capabilities for the apps table as listed by Stephen
  5. Listing extensions defined by an app.

Please include issues IDs here.

I’ve created issues:

  1. Viewing/editing built-in app’s config: https://issues.openmrs.org/browse/RA-1326
  2. Restoring app’s config: https://issues.openmrs.org/browse/RA-1327
  3. Exposing app’s config via rest: https://issues.openmrs.org/browse/RA-1328
  4. Filtering capabilities for the apps table as listed by Stephen: https://issues.openmrs.org/browse/RA-1330
  5. Listing extensions defined by an app: https://issues.openmrs.org/browse/RA-1329
1 Like

Good conversation, and sorry I was on vacation for it. :slight_smile:

Here is something I wrote before which relates to this: Managing App Definitions and Extensions in OpenMRS

Since we built the refapp, Bahmni has taken what I think is a better philosophical approach to the way these apps are set up, and I think we should draw inspiration from what they have done.

My quick thought about this is:

  • Upon first installation, we write the built-in app definitions to a config folder in the filesystem (like Bahmni does) or the database
  • Users are able to edit these just like any other apps