Replacing Modulus: Project Status Updates

Tags: #<Tag:0x00007f828f36d5a8>

Continuing the discussion from Replacing Modulus: Design Thoughts:

Executive Summary:

  • Good progress
  • Helping to exercise our ITSM processes
  • Blocker: Need to discuss what the MVP should be, and when we’d go live

Done since last update:

Next steps:

Further on:

  • Migration! (needs analysis)
  • support GitHub Releases
2 Likes

Could we promote fully qualified names for the uid – e.g., “org.openmrs.appui” instead of “appui-module”? We’ve wanted to migrate to fully qualified module IDs anyway to make it easier for people to create universally unique add-on identifiers without the need for a central registry.

1 Like

Good point. I committed a change for this.

1 Like

Good work!

Another update…

Executive Summary:

  • Good progress
  • Helping to exercise our ITSM processes
  • Blocker: Need to discuss what the MVP should be, and when we’d go live

Done since last update:

Next steps:

  • Define the MVP
  • make it look pretty (@reubenv is working on this)
  • implement the legacy API
  • show download stats (from bintray)
  • show ratings (from bintray)
  • tags/labels
  • “lists” of add-ons e.g. “list of modules in refapp 2.5”

Further on:

  • Migration! (needs analysis)
  • support GitHub Releases
3 Likes

Overdue for an update, so here’s the current status

Executive Summary:

  • We have been slow to do UI skinning, but hopefully this is unblocked now.
  • MVP was discussed, and we have a plan for going live alongside modules.openmrs.org as an MVP, with a larger set of functionality needed to fully replace it later on.

Done since last update:

In Progress:

  • make it look pretty (@reubenv is working on this); we were blocked on getting the tech right, but now are going with bootstrap CSS and https://react-bootstrap.github.io/ for JS. (This is the last piece of the MVP.)

Next steps ([R] means it’s required to replace modules.openmrs.org):

  • tags/labels
  • show download stats (just from bintray)
  • show ratings (from bintray)
  • locally store download stats (consistently across different backends) [R]
  • implement the legacy API [R]

Further on:

  • Migration! (needs analysis)
  • support GitHub Releases
2 Likes

Executive Summary:

  • We have been slow to do UI skinning, but @reubenv is making good progress with react-bootstrap
  • moving towards the MVP (started indexing the modules in Modulus)

Done since last update:

In Progress:

  • make it look pretty (@reubenv is working on this)

Next steps ([R] means it’s required to replace modules.openmrs.org):

  • tags/labels
  • show download stats (just from bintray)
  • show ratings (from bintray)
  • locally store download stats (consistently across different backends) [R]
  • implement the legacy API [R]

Further on:

  • Migration! (needs analysis)
  • support GitHub Releases
1 Like

Great work @darius

Executive Summary:

  • UI looks good now. Thanks @reubenv!
  • This is now better than modulus for searching for modules
  • we can highlight specific lists of modules
  • we can mark modules and deprecated or inactive
  • supports OMODs and OWAs
  • Try it at https://addons-stg.openmrs.org and let me know if there’s any reason not to go live with this now (would be a soft launch, alongside modulus, not yet replacing it). Also, I welcome anyone to put in the correct lists!

Done since last update:

  • UI enhancements (two big PRs from @reubenv, plus stuff by me)
  • optionally label addons as Active vs Inactive vs Deprecated
  • tagging of addons (e.g. “form-entry”)
  • improved search result weighting (still lots of room for improvement here)

In Progress:

  • nothing

Backlog ([R] means it’s required to replace modules.openmrs.org):

  • show download stats [R]
  • implement the legacy API [R]
  • better set of lists
  • filter all screens based on user-entered OpenMRS Platform version
  • show ratings
  • support GitHub Releases

Looking great @darius. I am really happy to see you guys bring this so far. I don’t see a project for this in JIRA (should we be using the existing modulus project)? A few comments:

  • I agree searching could use more refinement. Specifically, if I search for "report’, I’d like to see results with “report” explicitly in their name weighted higher than those with report somewhere in their description or other content. I’d also like to see deprecated add ons at the end of the list
  • If I search for, and click into an add on, there is no way to get back to my search results. There is no navigation back, and the back button does not preserve my previous state.
  • In the module list, it would be great to display (and search on) the moduleid rather than just the display name.
  • It would also be great to link back to the place that it is indexing (in case that is helpful), and also to the github repository (if specified, say, in the pom or config.xml, or somewhere)
  • Clicking on “All Types” shows “Highlighted Modules”, whereas clicking on “Modules” shows a list of 200 results, seemingly un-sorted and un-filtered. It would be great to have either of these act consistently, and also have an explicit way to page through all available modules. These should be sorted alphabetically.

Anyway, not sure if this is helpful or desired feedback, but I wanted to put it down somewhere and this seemed the best place to do it :slight_smile:

Nice work, Mike

1 Like

I replied at Replacing Modulus: Design Thoughts (My intention was for this thread to just be status updates, and the other thread for discussions, to enable better tracking for PM purposes. Thinking about it more, it’s probably best to just have a single thread, and just do periodic progress summaries on it.)

1 Like

Replying to Add-On Index enhancements here, because the other thread was made with the intention of gsoc discussions on the project.

It’s funny how the smallest of issues sometimes get us(me in this case) stuck :sweat_smile:. The reason for the console error was basically that although the new url pointed to “react-router”, it pointed to “react-router v4.0” whereas our project previously depended on “ReactRouter” which was part of V3.0.2 .

The next question is as to how did this happen in the first place?

The answer to this is that we previously used a url which was dynamic i.e. it gets resolved to a different one .The url used was this. This url basically points to the latest version of react router which is now V4.0 . Now, if we look into the contents of this resolved url , we realise that ReactRouter.min.js no longer exists and that only react-router.js is present. Hence , naturally I didn’t initially think that there’s going to be a difference between the two and created a pull request with a url pointing to react-router.js .

This new file missed some vital code on which our project currently depends and hence the console error . On checking the npm package.json file, I realised that we were using v3.0.2 and when I navigated to the React-router files of v3.0.2, I found the file right there. Hence I have now created an updated PR with the link to the exact same file. I have also tested it locally and can confirm that Add-On Index is back up and running :slight_smile: .

@darius Please check this .:slight_smile:

I went ahead and merged it since the CI passed.

cc: @darius

Thanks @r0bby. @cintiadr Can you please deploy the latest changes ?

In theory deployment should occur automatically. I will check why that didn’t happen.

Hum, the build failed. So I had to redeploy.

Thanks @cintiadr :slight_smile:.

Summary:

Add-ons is live again.

Thanks for fixing the problem :slight_smile:

2 Likes

:star2: for @reubenv

1 Like