From mn/ifi/inf5750
Revision as of 17:44, 2 December 2017 by Jagatds@uio.no (talk | contribs)

Jump to: navigation, search

Group members

  • Sharanan Kulam (sharanak@ifi.uio.no)
  • Jagat Deep Singh (jagatds@ifi.uio.no)
  • Tin Anh Nguyen (tinng@ifi.uio.no)
  • Son Thanh Vo (sontv@ifi.uio.no)


Master Facility List

GitHub repository (Hooli )

Product descriptions requirements


  • Users
    • F1: All users should be able to get a list of all organisation units, and be able to search and filter on it. A user should be able to filter based on organisation unit name, organisation unit groups, data sets, and a combination of these.
    • F2: All users should be able to view an organisation unit's information—all attributes, as well as: GIS coordinates on a map, when available; membership in organisation unit groups; data sets, and indicator values (stats).
    • F3: All users should be able to submit proposals for changes to the information of any organisation unit. These proposals should be stored for later inspection from an appropriate administrator.
  • Administrator
    • F4: Administrators should be able to view a list of submitted proposals for the organisation units in which they manage. I.e. administrators should only be able to see relevant proposals.
    • F5: Administrators should be able to view the content of a submitted relevant proposal. I.e. display the proposed changes, and possibly optional comments as to why the changes should be made.
    • F6: Administrators should be able to mark relevant proposals as resolved/invalid. Marked proposals should, by default, not be displayed to the administrators.
    • F7: Administrators should be able to choose which data elements and indicators are to be displayed for a given organisation unit, in which they manage. Normal users will, then, only be able to see the chosen data elements, when trying to view the organisation unit's information.


The app should be split into two main views: a user view; and an administrator view. This can be realized through a form of tabs. The former should be the view where all users may search and browse information on the different organisation units; while the latter should be the view displaying relevant proposals to the user (whom could be an administrator, or not—in which case it's empty)

The user view should again be split into three columns: one for search and filter; one for the list of query results; and one for the organisation profile, which displays information on the user-selected organisation unit. Clicking on a organisation unit from the query results should display its information in the profile column.

Searching should by done using a text field for the organisation unit name. And filtering can be further specified by adding tags corresponding to organisation unit groups and data sets. To add these tags, two combo boxes—with search—could be used. As for filtering on organisation unit hierarchy, this will have to be further studied.

To propose changes for an organisation unit; one solution could be to have a button appear on the organisation profile, which opens up a modal for editing/proposing changes. The modal should have buttons for submitting and/or discarding the proposals, one for each.

The administrator view can be split into two columns: one for the proposal list, which lists all of the relevant proposals; and one for the proposal view, which displays the text of proposed changes.

For resolving and invalidating proposals; two button at the top-right corner of the proposal view should suffice.


All components should be dumb—be fed information from the global state.

Data should only be fetched when needed (i.e. on demand), e.g. when the search query changes, or the user selects an organisation unit or proposal to view.

Proposals and configurations should be stored in the app's dataStore namespace:

       proposals: [
               id: [organisationUnitId],
               submitted: [dateSubmitted],
               status: ["pending"|"resolved"|"invalid"],
               changes: [textOfProposedChanges]
       configurations: {
           [organisationUnitId]: {
               dataElementSets: [


  • React - We chose React mainly due to its popularity, giving it a larger ecosystem. Compared to the other two big frameworks (Vue.js, Angular), we followed Goldolick's rule and chose React as it strikes a balance between simplicity (ease of learning) and scalability.
  • Semantic Css - We needed a CSS framework to reduce the amount of styling, and chose Semantic as it had a library providing a lot of pre-made React components—and was pleasing to the eye.

Division of work

We used Trello to organize the features (listed above) into descriptive tasks and sub-tasks. Initially, we assigned primary tasks to each member. During every weekly meeting we discussed the progress for each assigned tasks (e.g. reviewing the code/pull-request, discussing challenges, etc...), and distributed the tasks from the backlog for the upcoming week.

General overview of labour distribution:

  • Thanh Son: Organisation filter and organisation config (F1, F7)
  • Sharanan: Organisation search and admin proposals (F1, F4, F5, F6)
  • Deep: Organisation profile (F2, F3)
  • Tin: Communication between the app and the DHIS2 API and app architecture (F7)



Week 43

  • Studied requirements
  • Write wiki-page
    • Discussed framework and architecture
    • Setup time management
  • Setup project
  • Get familiar with react
  • Get familiar with DHIS2

Week 44

  • Implement search: organization unit
  • Implement filter: organization unit
  • implement display: organization unit

Week 45

  • Implement view: user proposing changes
  • implement view: admin reviewing proposals
  • Implement view: admin data display/configurations
  • Implement api for data store usage

Week 46

  • Feature extentions
  • Bug fixing

Week 47

  • Bug fixing

Week 48

  • The week where we actually do stuff