Permission checks and report filters

Hi all,

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:

  1. An environment setting that makes (some of?) our GET endpoints accept the VIEW_REPORTS right.

  2. Simplified proxy-like endpoints in reporting service that return only the data that’s required for the filter (id, name, code?)

Best Regards,

Jakub

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:

  1. what API’s and Service versions are each report based on (down to the data field level)
  2. 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.

Best,
Josh

···

On Thursday, August 10, 2017 at 9:26:14 AM UTC-7, jkondrat@soldevelo.com wrote:

Hi all,

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:

  1. An environment setting that makes (some of?) our GET endpoints accept the VIEW_REPORTS right.
  1. Simplified proxy-like endpoints in reporting service that return only the data that’s required for the filter (id, name, code?)

Best Regards,

Jakub

Just want to +1 Josh’s comments here —

Documentation/requirements are essential for us to really hone in on the best solution …

···

From: openlmis-dev@googlegroups.com on behalf of Josh Zamor josh.zamor@villagereach.org

Date: Thursday, August 10, 2017 at 11:14 PM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

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:

  1. what API’s and Service versions are each report based on (down to the data field level)
  2. 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.

Best,

Josh

On Thursday, August 10, 2017 at 9:26:14 AM UTC-7, > jkondrat@soldevelo.com wrote:

Hi all,

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:

  1. An environment setting that makes (some of?) our GET endpoints accept the VIEW_REPORTS right.
  1. 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.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/ed28feae-4330-4074-ad30-6a61c21e3698%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

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.

Currently we have some notes and features outlined here : https://openlmis.atlassian.net/wiki/spaces/OP/pages/112138662/Reporting+and+Analytics

In addition you can see some of the eLMIS reporting needs under this parent page on the wiki : https://openlmis.atlassian.net/wiki/spaces/OP/pages/105578547/Gap+Analysis+eLMIS+Tanzania+Zambia+and+OpenLMIS+3.x

Let me know how I can support.

···

From: openlmis-dev@googlegroups.com openlmis-dev@googlegroups.com on behalf of Jake Watson jake.watson@villagereach.org

Sent: Friday, August 11, 2017 1:08:25 PM

To: Josh Zamor; OpenLMIS Dev

Subject: Re: [openlmis-dev] Re: Permission checks and report filters

Just want to +1 Josh’s comments here —

Documentation/requirements are essential for us to really hone in on the best solution …

From: openlmis-dev@googlegroups.com on behalf of Josh Zamor josh.zamor@villagereach.org

Date: Thursday, August 10, 2017 at 11:14 PM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

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:

  1. what API’s and Service versions are each report based on (down to the data field level)
  2. 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.

Best,

Josh

On Thursday, August 10, 2017 at 9:26:14 AM UTC-7,
jkondrat@soldevelo.com wrote:

Hi all,

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:

  1. An environment setting that makes (some of?) our GET endpoints accept the VIEW_REPORTS right.
  1. 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.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/ed28feae-4330-4074-ad30-6a61c21e3698%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/D5B35C97.133B7%25jake.watson%40villagereach.org
.

For more options, visit https://groups.google.com/d/optout.