From mn/ifi/inf5750
Revision as of 15:55, 25 October 2017 by Sontv@uio.no (talk | contribs)

Jump to: navigation, search


Hooli ;)

Group members

  • Sharanan Kulam
  • Jagat Deep Singh
  • Tin Anh Nguyen
  • Son Thanh Vo


Master Facility List

Product descriptions requirements


  • Users
    • 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, organisation unit hierarchy, data sets, and a combination of these.
    • 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).
    • 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
    • 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.
    • 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.
    • Administrators should be able to mark relevant proposals as resolved/invalid. Marked proposals should, by default, not be displayed to the administrators.
    • 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: [