While working on Malawi’s reports, we’ve encountered an issue with permissions. A user with REPORTS_VIEW right was not able to enter the report’s page, because the filters specified within that report required additional rights - UI had to fetch a list of geographic zones, programs, processing periods or stock adjustments. When designing the report, one could actually make a filter that calls any of the GET endpoint. We got around this by creating some proxy (service-level) endpoints that fetched the data for the user.
Since future implementations might have the same problem and Malawi is likely migrating to openlmis-report service, we should have a solution that works for everyone.
Here are some options I could think of:
An environment setting that makes (some of?) our GET endpoints accept the VIEW_REPORTS right.
Simplified proxy-like endpoints in reporting service that return only the data that’s required for the filter (id, name, code?)
Thanks for asking as I’d suggest being careful about spending effort here.
The original intention before Malawi introduced the hard-coded reports in this Service was to have a simplistic (overly simplistic) report service that used direct SQL defined in the report, including filters based on SQL and not API calls. This is an approach that worked in v1 and one which I wanted to leverage as a quick and only temporary solution until we had data-pumps. Data-pumps and a more-robust reporting service which had its own reporting database would give us a number of advantages, one of which is this filtering / permissions issue; though the larger wins also include less fragile report definitions when upgrading and negating performance impacts of running reports on operational services (e.g. Requisitions).
Given the challenges we’ve had in getting the Malawi reports service requirements solidified and a service contributed back to OpenLMIS which everyone can leverage, I think our collective effort would be better spent communicating what Malawi needs (filters, customizable logos, etc) for a future 3.X release of OpenLMIS, and for Malawi to continue its present path with its own reporting service using “proxy-like” endpoints.
The OpenLMIS plan meanwhile should be to take the openlmis-report service contributed thus far from Malawi and evolve it toward the generic data-pump future - including Malawi needs such as customizable logos defined outside of the report itself (a feature that Jasper Server is well adapted to). This work will likely conclude sometime after the 3.2 release (just a few short weeks away).
I would encourage the Malawi team to carefully document alongside each report what are the critical requirements:
what API’s and Service versions are each report based on (down to the data field level)
what functionality is required (e.g. customizable logos, when it’s defined and how is it deployed)
While I think I know the outline of most of #2 above, having it written down will help future release planning. #1 meanwhile will be very useful when planning for future Malawi upgrades - weather it’s to a future OpenLMIS reporting service or a future Tableau WDC solution.
While working on Malawi’s reports, we’ve encountered an issue with permissions. A user with REPORTS_VIEW right was not able to enter the report’s page, because the filters specified within that report required additional rights - UI had to fetch a list of geographic zones, programs, processing periods or stock adjustments. When designing the report, one could actually make a filter that calls any of the GET endpoint. We got around this by creating some proxy (service-level) endpoints that fetched the data for the user.
Since future implementations might have the same problem and Malawi is likely migrating to openlmis-report service, we should have a solution that works for everyone.
Here are some options I could think of:
An environment setting that makes (some of?) our GET endpoints accept the VIEW_REPORTS right.
Simplified proxy-like endpoints in reporting service that return only the data that’s required for the filter (id, name, code?)
Subject: [openlmis-dev] Re: Permission checks and report filters
Hi Jakub,
Thanks for asking as I’d suggest being careful about spending effort here.
The original intention before Malawi introduced the hard-coded reports in this Service was to have a simplistic (overly simplistic) report service that used direct SQL defined in the report, including filters based on SQL and not API calls. This is an approach that worked in v1 and one which I wanted to leverage as a quick and only temporary solution until we had data-pumps. Data-pumps and a more-robust reporting service which had its own reporting database would give us a number of advantages, one of which is this filtering / permissions issue; though the larger wins also include less fragile report definitions when upgrading and negating performance impacts of running reports on operational services (e.g. Requisitions).
Given the challenges we’ve had in getting the Malawi reports service requirements solidified and a service contributed back to OpenLMIS which everyone can leverage, I think our collective effort would be better spent communicating what Malawi needs (filters, customizable logos, etc) for a future 3.X release of OpenLMIS, and for Malawi to continue its present path with its own reporting service using “proxy-like” endpoints.
The OpenLMIS plan meanwhile should be to take the openlmis-report service contributed thus far from Malawi and evolve it toward the generic data-pump future - including Malawi needs such as customizable logos defined outside of the report itself (a feature that Jasper Server is well adapted to). This work will likely conclude sometime after the 3.2 release (just a few short weeks away).
I would encourage the Malawi team to carefully document alongside each report what are the critical requirements:
what API’s and Service versions are each report based on (down to the data field level)
what functionality is required (e.g. customizable logos, when it’s defined and how is it deployed)
While I think I know the outline of most of #2 above, having it written down will help future release planning. #1 meanwhile will be very useful when planning for future Malawi upgrades - weather it’s to a future OpenLMIS reporting service or a future Tableau WDC solution.
While working on Malawi’s reports, we’ve encountered an issue with permissions. A user with REPORTS_VIEW right was not able to enter the report’s page, because the filters specified within that report required additional rights - UI had to fetch a list of geographic zones, programs, processing periods or stock adjustments. When designing the report, one could actually make a filter that calls any of the GET endpoint. We got around this by creating some proxy (service-level) endpoints that fetched the data for the user.
Since future implementations might have the same problem and Malawi is likely migrating to openlmis-report service, we should have a solution that works for everyone.
Here are some options I could think of:
An environment setting that makes (some of?) our GET endpoints accept the VIEW_REPORTS right.
Simplified proxy-like endpoints in reporting service that return only the data that’s required for the filter (id, name, code?)
Best Regards,
Jakub
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.
I echo Josh’s comments. I am very interested in better understanding Malawi’s needs. I’d like to participate in the process, either by reviewing or listening in on the conversation. The sooner we can document and incorporate them into roadmap the better.
Subject: [openlmis-dev] Re: Permission checks and report filters
Hi Jakub,
Thanks for asking as I’d suggest being careful about spending effort here.
The original intention before Malawi introduced the hard-coded reports in this Service was to have a simplistic (overly simplistic) report service that used direct SQL defined in the report, including filters based on SQL and not API calls. This is an approach that worked in v1 and one which I wanted to leverage as a quick and only temporary solution until we had data-pumps. Data-pumps and a more-robust reporting service which had its own reporting database would give us a number of advantages, one of which is this filtering / permissions issue; though the larger wins also include less fragile report definitions when upgrading and negating performance impacts of running reports on operational services (e.g. Requisitions).
Given the challenges we’ve had in getting the Malawi reports service requirements solidified and a service contributed back to OpenLMIS which everyone can leverage, I think our collective effort would be better spent communicating what Malawi needs (filters, customizable logos, etc) for a future 3.X release of OpenLMIS, and for Malawi to continue its present path with its own reporting service using “proxy-like” endpoints.
The OpenLMIS plan meanwhile should be to take the openlmis-report service contributed thus far from Malawi and evolve it toward the generic data-pump future - including Malawi needs such as customizable logos defined outside of the report itself (a feature that Jasper Server is well adapted to). This work will likely conclude sometime after the 3.2 release (just a few short weeks away).
I would encourage the Malawi team to carefully document alongside each report what are the critical requirements:
what API’s and Service versions are each report based on (down to the data field level)
what functionality is required (e.g. customizable logos, when it’s defined and how is it deployed)
While I think I know the outline of most of #2 above, having it written down will help future release planning. #1 meanwhile will be very useful when planning for future Malawi upgrades - weather it’s to a future OpenLMIS reporting service or a future Tableau WDC solution.
While working on Malawi’s reports, we’ve encountered an issue with permissions. A user with REPORTS_VIEW right was not able to enter the report’s page, because the filters specified within that report required additional rights - UI had to fetch a list of geographic zones, programs, processing periods or stock adjustments. When designing the report, one could actually make a filter that calls any of the GET endpoint. We got around this by creating some proxy (service-level) endpoints that fetched the data for the user.
Since future implementations might have the same problem and Malawi is likely migrating to openlmis-report service, we should have a solution that works for everyone.
Here are some options I could think of:
An environment setting that makes (some of?) our GET endpoints accept the VIEW_REPORTS right.
Simplified proxy-like endpoints in reporting service that return only the data that’s required for the filter (id, name, code?)
Best Regards,
Jakub
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.