This document includes brainstorming notes from the Ona Team:
3 months --> December 5 -- March
- Functional enhancements to Superset
- Drilldown
- Conditional formatting in tables
- Annotations to bar charts
- Drilldown
- Pop-up with new indicator
- Legend
- Admin ability to upload shapefiles more easily
- Build a new user model specifically for OLMIS to make sure that within Superset the user model is queried instead of having the WHERE clause in the indicator
- Not sure if WHERE clause is secure
- Test whether someone with VIEW permissions can hack it and remove the WHERE class
- Do we need to restrict someone's edit permissions to their current role?
- Superset is built on FAB --> FAB doc'n talks about extending user model to collect other fields
- PDF
- Headers/footers/logos
- Chart
- --> modify CSS to dynamically display what dashboard should look like
- XLSX
- Add nice logos and headers to CSV
- Specifically say what the column is supposed to be
- Add footers (metadata of export)
- Make a dashboard responsive based on browser's size
- Create a print layout --> media query --> when you press Print button you can define size of thing you want to print and specifically adjust layout to be formatted appropriately for the page
- Align look and feel of Superset dashboards with OLMIS style guide
- Visualization
- Map-specific
- Dashboard-level access controls
- Row-level filtering
- Exports
- Modify CSS
- Stock management reporting in Postgres for 3.6?
- SSO
- Improvement around when login occurs
- Kafka
- Develop a use case that plays to Kafka's strengths
- Test it
- Document it
- Data pumps
- Debezium - The reporting team uses the API and extracts it. This tool allows us to let the service owner define what gets sent to the reporting stack.
- Instead of fetching the data, we would be able to receive it as it happens.
- Can we fit this in with DHIS2?
- Make reports available or post them to DHIS2
- DevOps
- Clearly identify DevOps requirements with Peter
- Reporting stack we've built have been built for developer use, not production use
- Persist data
- Figure out how to upgrade each individual service in a way that retains the data and possibly migrates it
- Biggest risk is upgrading NiFi
- Kafka
- NiFi auto load sensitive values
- Superset auto load custom user roles
- Superset auto load dashboards + charts
- NiFi registry and RBAC
- Add a "retrieve all" token that returns all requisitions regardless of the user's permissions
Additional Meeting Notes from meeting on 20 Nov 2018
Attendees:
Discussion:
- Attendee Priorities:
- Josh: DHIS2 and devops only if it makes it easier for new teams to learn. We need to make it useful to deploy for developers in production.
- Clay: Devops and improvement of SSO
- Craig: Devops and Superset row level filtering/permissions
- Wes: DHIS2, exports from Superset (power users need to have access to the data) and visualizations. We need to build capacity of the team.
- Mary Jo:
- Musts:
- Knowledge Transfer - will be meeting in person
- DHIS2
- Priority:
- Superset enhancements (TBD)
- Next:
- Scope DHIS2
- Decide on the scope and there are really only two pieces of work:
- Create Level of Effort of things we can't get
- Create an epic for each with the Component as "Reporting"
- To prepare for Zambia:
- Who is going to be working on what?
- They want a holistic list of what is in OpenLMIS v3.6
- Review the Epics that are in Reporting and mark them dead
Further Discussion 20 Feb 2019
Attendees: Wesley Brown, Clay Crosby (Unlicensed), Craig Appl (Unlicensed)
Discussion:
- There's a risk in the FHIR approach that Craig is bringing up with Josh
- It looks like BAO will do the DHIS2 transportation, so we will descope Ona's role on that.
- Ona will be responsible for providing an interface for the reporting solution using a standard
- Things that need to be done should be done by sprint 121 - 27th March
- Production Readiness is nearly done
- Persisting information in Superset is done
- Decisions:
- CSS Modifications
- Print PDFs
- Nifi Security is too big with a small value add
- Continue with building standard interface that can be consumed by DHIS2