6) Epic: Admin Lists UI

[pfitzpaddy]

Currently, the only way to update ngm-lists is via a database update.

SUPERUSER should have access to manage RH master lists (which are the default lists to new countries).

SUPERADMIN, COUNTRY, CLUSTER ADMINs should have access to manage RH lists for specific country / cluster response that are selected from the MASTER list

Tasks

• [x] Create an Admin page at '/cluster/admin/lists' that provides access to RH MASTER lists (default) [ Organizations, Donors, Activities, Stocks, Beneficiaries, Units ] as cards for [ SUPERADMIN ]
• [x] Create an Admin page at '/cluster/admin/lists' that provides access to RH COUNTRY response lists [ Organizations, Donors, Activities, Stocks, Beneficiaries, Units ] as cards for [ SUPERADMIN, COUNTRY, CLUSTER ] Admin
• [ ] Create an Admin page at '/cluster/admin/lists/updates' that provides a list of updates from COUNTRY / CLUSTERs for review and acceptance by SUPERADMIN.

Notes

• [ ] All lists should have a character limit specified.
• [ ] Only SUPERADMIN can see MASTER lists
• [ ] Updates to [ Organizations, Donors, Activities, Stocks, Beneficiaries, Units ] list by COUNTRY, CLUSTER admins goes back into the MASTER list.
• [ ] SUPERADMIN receives alert when new activity is added to a COUNTRY / CLUSTER response for review.
• [ ] For a COUNTRY response, list items are enabled / disabled (not deleted).
• [ ] COUNTRY / CLUSTER can not see MASTER list.

Access

• [ ] SUPERADMIN should be able to edit [ Organizations, Donors, Activities, Stocks, Beneficiaries, Units ] RH MASTER lists.
• [ ] SUPERADMIN reviews a list of new additions from various COUNTRIES / CLUSTERs and activates to enable the new addtions
• [ ] COUNTRY Admins should be able to edit [ Organisations, Donors, Beneficiaries ] for country response only
• [ ] COUNTRY Admins should be able to view [ Activities, Stocks, Units ] for country response only by CLUSTER (from left menu)
• [ ] CLUSTER Admins should be able to edit [ Organizations, Donors, Activities, Stocks, Beneficiaries, Units ] for COUNTRY response only

Menu

• [x] SUPERADMIN: Master lists always visible
• [x] SUPERADMIN: Provide a left menu navigation that filters lists by COUNTRY (does not contain ALL filter)
• [x] SUPERADMIN: Provide a left menu navigation that filters lists by CLUSTER (does not contain ALL filter)
• [x] [ COUNTRY, CLUSTER ]: Hide MASTER lists and display COUNTRY level response lists only (no options in left menu for COUNTRY selection.
• [x] COUNTRY: Provide a left menu navigation that filters lists by CLUSTER (does not contain ALL filter)
• [x] [ CLUSTER ]: Hide CLUSTER filter for CLUSTER admin users.

Organizations

• [ ] Organizations can be searchable from a global RH list and made active / not-active for a country response.
• [ ] Organisations can be added to the master RH list (if missing) via searching from HDX or being manually added.
• [ ] Any updates to Organisations should be reflected throughout all existing data

Donors

• [ ] Donors can be searchable from a global RH list and made active / not-active for a country response.
• [ ] Donors can be added to the master RH list (if missing) via searching from HDX or being manually added
• [ ] Any updates to Donors should be reflected throughout all existing data.

Activities

• [ ] For Activities, lists should be grouped into response plans or years.
• [ ] Activities list should have a date range for when they are active (i.e. activities for 2019-2022 plan should become active from 2019 reports).
• [ ] For Activities, an activity can be made active (i.e. it appears in dropdown lists for users to report on) or not-active (users do not see the activity in the dropdown list, only in previous reports).
• [ ] i.e. When looking at 2018 reports, the 2018 list should be fetched for the UI dropdowns.
• [ ] Updating an active list will update relevant data throughout the database for those years.
• [ ] Update an old list will update relevant historical data throughout the database
• [ ] Activities can be 2-tier (default) or 3-tier (i.e. Nigeria)
• [ ] Activities should be draft and then "deployed" to make it clear to the IMO that the partners will now start reporting on the Activities list
• [ ] Provide ability for Admin to preview the dropdown list.
• [ ] A disclaimer is needed that any major updates can cause problems (wording needs work).
• [ ] Activities will include indicator_id and indicator
• [ ] For each Activities, a series of checkboxes should be made available to determine the following keys for each activity [ cash, units, HH, families, b, g, m, w, e_m, e_w, ] including defaults.

Stocks

• [ ] Stocks can be searchable from a global RH list and made active / not-active for a country response.
• [ ] Any updates to Stocks should be reflected throughout all existing data.

Beneficiaries

• [ ] For Beneficiaries, lists should be grouped into response plans or years and can be active / not-active.
• [ ] Beneficiaries list should have a date range for when they are active (i.e. activities for 2019-2022 plan should become active from 2019 reports).
• [ ] When looking at 2018 reports, the 2018 list should be fetched for the UI dropdowns.
• [ ] Updating an active list will update relevant data throughout the database for those years.
• [ ] Update an old list will update relevant historical data throughout the database
• [ ] Beneficiaries in Active or historical lists can only be made not-active (they can not be deleted if there are records existing in the database).

Units

• [ ] Units can be searchable from a global RH list and made active / not-active for a country response.
• [ ] Any updates to Units should be reflected throughout all existing data.

[drfaustusfade]

UI/UX activities management sketch

[pfitzpaddy]

For this, I currently have "active" in activities.csv but thats not correct. What we could do is

• have a start_date, end_date, activity_tag (unique to date range) of each activity and then filter activities based on project_start_date, project_end_date at the initial time of project creation, and;
• assign the tag to the project based on the list used at the time of creation, for future manipulation (to query by tag, not date range, which might be extended, during the life cycle of the project).

[pfitzpaddy]

Bumping this issue, I think we should make a first start on this for the more basic lists, eventually tackling the more difficult issue of activities.

1. To begin, there should be an Admin landing page @ #/cluster/admin Note: the Access conditions are specified above in the first comment of this issue
2. The landing page will include [ Cluster (links to the default landing page @ #/cluster/organization), Dashboards (@ #/cluster/admin/etc), Lists (@ #/cluster/admin/lists) ]. Note, there might be a route conflict on #/cluster/admin, something to keep in mind.
3. This Admin page should also be available from the left menu (My Admin), along with the sub links.
4. The admin lists would then be available @ #/cluster/admin/lists (as described in the Tasks above)

The first lists to tackle could be organizations, donors and beneficiary types. Side Note An Organization might also be a of type donor, programme partners, implementing partner, but no need to worry about that now.

I suggest starting to integrate the code as soon as possible, making the pages visible only to our accounts (i.e. user.email === 'pfitzgerald' && user.email === 'tkilkeiev' && user.email === 'farifin', etc, or whatever accounts us 3 are using). This way we can have the code integrated and reviewed and rolled out with so many other changes ongoing easily.

[pfitzpaddy]

I recommend @fakhrihawari to take a look at this, unless you have other pressing issues. Any questions or clarifications contact Skype group Alpha at any time.

[drfaustusfade]

next on the list to tackle, after there is rtl support almost implemented, the good thing @fakhrihawari worked on it and did many things, the plan is to start with beneficiary types I support the idea of the practice of committing early and often

[fakhrihawari]

@pfitzpaddy and @drfaustusfade so what should we call this admin "master"?

[fakhrihawari]

Init : https://github.com/fakhrihawari/ngm-reportHub/tree/admin-list-2.0

[pfitzpaddy]

Adding another page we might want to add during this admin development -> APIs. The API card would load a page with lists of APIs and the params. This would be useful for the IMOs to access data. This is low priority and not urgent. With APIs, we should also look into adding a key param for security or including something for authentication - whatever we choose it would have to also work with Power Bi

[fakhrihawari]

Are beneficiary types and beneficiaries the same things? Cause in the task above just mention the detailed task about beneficiaries, not detailed task about the beneficiary type

[drfaustusfade]

In the task it’s the same, beneficiary type in RH is population group to provide services, meaning people, beneficiaries are also people served in general, hence the confusion, also it can be viewed as subclass of beneficiaries

[pfitzpaddy]

APIs Page -> Could be a page that also generates API key for user.

[drfaustusfade]

PROPOSAL/DISCUSSION for admin lists structure

The main idea is to organize all lists by Response Plan

Page for country admin/cluster admin would include: Global lists for view, Country lists (Organizations, Admins, ...), Plans

Plans -> List of Plans -> Plan Def & List of Clusters -> Plan Cluster lists ( Cluster...Beneficiary types, Activities, Donors, Site Types, Site Implementations, Indicators, Units, etc )

Each list would be referenced by PlanID, dates, tag etc A list would follow usual card form like interface, for country cluster list it would be possible to select values from global or maybe also functionality to add custom values The functionality of all components could be adjusted per Response Plan, for example, 5w would contain for Response Plans filter etc PlanID, PlanTag, could be added to beneficiary data, for reference and updates Further development could include Copy Plan, Plan Templates etc The first version could contain just one continuous ongoing plan for simplicity