Aanund Nordskog (email@example.com)
Nicole Keppler (firstname.lastname@example.org)
Saliha Sajid (email@example.com)
Henrik Halvorsen Hortemo (firstname.lastname@example.org)
MFL is a DHIS2 application for searching, browsing and proposing changes to organisation units, as requested by the Master Facility List assignment.
Our understanding of the assignment is reflected by the following user stories:
- As a user I want to find specific organization units
- As a user I want to search for organization units by name
- As a user I want to filter my search results by unit group membership
- As a user I want to filter my search results by ancestor relationships
- As a user I want to filter my search results by which data sets are assigned to the organization units
- As a user I want to see detailed information on a particular organization unit
- As a user I want to see all attributes of a particular organization unit
- As a user I want to see the location of a particular organization unit
- As a user I want to see which organization unit groups a particular organization belongs to
- As a user I want to see what data sets are assigned to a particular facility
- As a user I want to see data element and/or indicator values for the particular organisation unit for the current/last year
- As an administrator I want to select what data elements and/or indicators to display
- As a user I want to propose changes to organization units
- As a user I want to propose changes to organization unit attributes
- As an administrator I want to review submitted proposals
- As an administrator I want to mark proposals as resolved/invalid
Our initial UI/UX approach is reflected by the following mockups:
The application can be found in DHIS2 under MasterFacilityList-Application
MFL is designed as a client/server application where the DHIS2 server is responsible for data storage and data access logic, whereas the client is responsible for application logic and presentation logic.
Starting off, we really wanted to make something consistent with existing DHIS2 apps. Therefore, we looked into DHIS2 libraries such as dhis2/app-skeleton and dhis2/d2-ui. Unfortunately, we found the documentation for some of these libraries to be lacking. So rather than using these libraries, we identified and chose some of their core underlying frameworks, most notably React, Redux and material-ui. These are also hugely popular frameworks that all of the group members were eager to learn more about.
The client is therefore developed as a Single-Page Application (SPA) using Facebook's React view framework and the Redux architecture.
At its core is a normalized Redux store that serves as a single source of truth for the application state. This state is changed by emitting actions (objects describing what happened). When actions involves API interactions, they will wait for a response before dispatching the relevant action(s).
The normalization of data in the Redux store greatly simplifies handling of the nested JSON objects returned from the DHIS2 API, as it avoid data duplication and allows different parts of the app to easily reuse data fetched by other parts.
Using React, the view part of the app has a component-based architecture. In MFL, these are divided between connected components (containers) and presentational components.
The connected components are focused on how things work; they subscribe to the Redux state through its selector functions, dispatch Redux actions and pass relevant data and callback functions as props to (one or more) child components. The container components maps more or less to the different screens of the application.
The presentational components are concerned with how things look (markup and style). They are not aware of Redux, but read data and callback functions solely from passed props. This makes them reusable in different context.
This separation of concern makes the application easy to reason about and makes it easy for contributors to work on different parts of the app simultaneously.
We chose to use the MIT license for our application. This license is permissive, the wording of the licenses is very simple and easy to understand. We had to check that the MIT license didn’t violate any licenses used by any framework or libraries that we use in our code. We used a license checker to check if there was any conflict. After running license-checker, this is what we got:
├─ MIT: 826
├─ ISC: 63
├─ BSD-3-Clause: 61
├─ Apache-2.0: 19
├─ BSD-2-Clause: 18
├─ BSD*: 12
├─ MIT*: 4
├─ BSD: 3
├─ CC-BY-4.0: 2
├─ Apache License, Version 2.0: 2
├─ Unlicense: 2
├─ BSD-3-Clause OR MIT: 1
├─ Public Domain: 1
├─ UNLICENSED: 1
├─ (WTFPL OR MIT): 1
├─ (BSD-2-Clause OR MIT OR Apache-2.0): 1
├─ WTFPL: 1
├─ Custom: http://example.com/base.js: 1
├─ (MIT AND CC-BY-3.0): 1
├─ LGPL-2.1+: 1
├─ (GPL-2.0 OR MIT): 1
├─ Apache*: 1
└─ AFLv2.1,BSD: 1
Most of these licenses are permissive as the MIT license, Apache 2.0, BSD, CC-BY, ISC, AFL, WTFPL. The LGPL license was use in a library so we do not violate this license by our MIT. And the GPL or MIT license is a dual license so we can chose which one that should apply.
Division of labour
- Aanund Nordskog
- Search results, admin view, queries
- Nicole Keppler (email@example.com)
- Detail view of organisation unit
- Saliha Sajid (firstname.lastname@example.org)
- Sidebar and Filtering
- Henrik Halvorsen Hortemo (email@example.com)
- API queries and state management (Redux)