Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Meeting:

SPARC OS Technical Committee

Date:

Time:

2:00 pm - 2:31 pm

MUSC

Greg, Brigette

Iowa

LA CaTS

Ying

Children’s National

Case Western

Jeremy

OHSU

Stony Brook Medicine

Morehouse

Agenda

Discussion:

  • SPARCReport permissions - limiting data access per in SPARCCatalog structure. Topic previously raised by Jeremy for desire to limit report query and results to data related to program/provider levels. They have external reports but appreciate the real-time content within SPARC. Ying shared that only their Evaluation team accessed reports, so they have not had a need to differentiate the access. MUSC falls in the middle - multiple providers have access to it, but there’s been no reported issues.

Reviewed different user rights permissions:

  • SPARCCatalog management - SPARCReport that only requires Super User Rights

  • SPARCCatalog management - - SPARCForms builder with combo of Super User, Catalog Manager and Service Provider rights. Future direction to potential remove Catalog Manager right and put builder within SPARCForms to contain all forms functions within that space

    • SPARCForms query limited to Service Provider studies. However, all data are viewable in SPARCReports with a Super User right

  • SPARCCatalog management - - SPARCFulfillment: in Catalog, a program adds a ‘fulfillment tag’ where providers are then added into a Fulfillments rights section. Fulfillment reports data is limited.

  • SPARCAdmin management - Overlords. This, however, only gives additional function (e.g., Add/Modify requests) to areas permissions already granted so may not be best to mirror in this case.

  • Potential design could keep current permission structure to add a SPARCReports column in Catalog to manage those rights at the program/provider/core level, removing the Super User tie. Similar thought for SPARCForms. Consider:

    • Complexity of translating this to reports access, query and results

    • Whether this is customizable or must be accept by all institutions

    • If it should be design based on another method

Institutional Updates:

Louisiana Clinical & Translational Science Center: 

...

  • not in attendance

2/14/2024

  • Technical difficulties during updates - will send any questions or concerns or let Brian share at the upcoming Ops call

...

MUSC:

1/17/2024

  • Released SPARC v3.12.0 (Dec 14th) and v3.12.1 (Jan 10th). Both releases available to OS Community - see blog

  • Working on SPARCFulfillment planned deployment March 21st.

  • SPARC Ruby & Ruby Rails upgrades happening as Fulfillment work being done.

  • OS Governance Dec 1th 11th meeting reviewed MOU demo and is ok with including as a SPARC, customizable feature. Next step is a story describing the work.

2/14/2024

  • Working on SPARCFulfillment planned deployment March 21st

  • SPARC Ruby & Ruby Rails upgrades simultaneous to Fulfillment - tentative deployment end of March 2024, then will work on next SPARC Release

...

Oregon Health & Science University:

...

  • Working on upgrade

2/14/2024

  • not in attendance

...

Iowa

1/17/2024

  • not in attendance

2/14/2024

  • not in attendance

...

Case Western

1/17/2024

  • Still working toward upgrading to SPARC 3.11.0. Current issue is that ldap isnt going to their institutional login page. Andrew was able to join to give some guidance that ldap is used for adding user to studies, not to present a login page He gave some code base location Jeremy should look at:

    • config/initializers/devise.rb, line 41

    • They may need to use https://github.com/omniauth/omniauth-ldap gem for authentication.

    • config/cas.yml file is a part of code base and a part of v3.11. This is a config file to read db so no need to add to settings.

  • Asked if giving access to Reports allows users to run reports on all SPARC services or only those they can access. His testing showed global access. This should limit to only what they can access, so he’ll check permissions for other access like Super User or Overlord rights. Brigette will do some testing as well to confirm behavior.

    • Post meeting, testing shows SPARC design where being a super user at any Org level lets you have access to SPARCReports with ability to run reports for all. Worth a discussion to see if this should be limited, similarly to how SPARCForms limits to surveys and forms particular to orgs/services.

2/14/2024

  • Upgraded test server to SPARC 3.12.1. Finished RedHat 8 upgrade, no addl updates yet. Next step is copying code. Jeremy will be out thsi Friday and will be absent from the OS Ops Governance call.

...

Children’s National

1/17/2024

  • not in attendance

2/14/2024

  • not in attendance

...

Stony Brook:

1/17/2024

  • not in attendance

2/14/2024

  • not in attendance

...

Morehouse:

1/17/2024

  • They are picking SPARC back up for implementation and will reach out with any questions.

2/14/2024

  • not in attendance

...