Meeting: | SPARC OS Technical Committee |
|---|---|
Date: | 31 Jan |
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:
No planned discussion items; see MUSC update sectiontitutional 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:
1/17/2024
not in attendance
12/3114/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.
12/31/202414/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:
1/17/2024
Working on upgrade
12/3114/2024
not in attendance
...
Iowa
1/17/2024
not in attendance
12/3114/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.
12/31/202414/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
12/3114/2024
not in attendance
...
Stony Brook:
1/17/2024
not in attendance
12/3114/2024
not in attendance
...
Morehouse:
1/17/2024
They are picking SPARC back up for implementation and will reach out with any questions.
12/3114/2024
not in attendance
...