Okapi Permissions-to-Eureka Roles Converter Project
Feature Description
This feature involves developing an upgrade tool and process that translates Okapi Permissions and Permission Sets into Eureka Capabilities and Roles. The goal is to ensure that library administrators can manage the new Role-Capability structure effectively in Eureka, preserving operational logic and maintainability.
Challenges with the Existing Upgrade Process
(Per Vince B’s documentation)
Unlimited Nesting:
Okapi Permission Sets support nesting with no restriction on nesting levels.Institutional Customization:
Permission Sets have been carefully curated and customized at each institution to create logical groupings for assigning staff permissions based on operational needs.Current Migration Tool Limitations:
The existing Eureka migration tool offers basic conversion: it migrates users from Okapi Folio to Eureka Folio without loss of user functionality.
However, this comes at a cost—carefully constructed permission sets and their logical, maintainable structure are mostly lost. The resulting configuration is difficult for library administrators to manage and adapt.
Proposed Solution: Flattening Before Migration
To address this, we propose flattening the existing Okapi permission structure prior to migration. This means:
Flatten Nested Permission Sets:
Break down nested Permission Sets into flat, non-nested lists, preserving all the operational permissions assigned to each staff member.Map Flat Sets to Capabilities and Roles:
Translate these flat Permission Sets into Eureka Capabilities and group them into Roles that mirror the institution’s logical groupings as much as possible.Maintainability:
The resulting Role-Capability structure in Eureka will be more transparent, easier to understand, and more maintainable for library administrators post-upgrade.
Next Steps
Define a flattening algorithm that preserves all permission logic.
Develop mapping rules from Okapi Permissions/Sets to Eureka Capabilities/Roles.
Provide a migration preview/report so admins can review mappings before committing.
Rough Implementation Plan
| 1 | Week 1 | 5/26-5/30 |
|
| 2 | Week 2 | 6/2-6/6 | Analyze the data - done |
| 3 | Week 3 | 6/9-6/13 | Map capability-role structure - in progress |
| 4 | Week 4 | 6/16-6/20 |
|
| 5 | Week 5 | 6/23-6/27 |
|
| 6 | Week 5 | 6/25 | Environment A and B created
|
| 7 | Week 6 | 6/30-7/4 (short week in USA) |
|
| 8 | Week 7 | 7/7-7/11 |
|
| 9 | Week 8 | 7/14-7/18 |
|
| 10 | Week 9 | 7/21-7/25 | Continue testing and fixing script defects |
| 11 | Week 10 | 7/28 - 8/1 | Continue testing and fixing script defects ICs provide list of test users for NLA and Cornell - done Fix Eureka defects |
| 12 | Week 11 | 8/4-8/8 | Finishing Distributed and testing Consolidated Strategies and Cleanup in Test Env Prepare NLA and Cornell envs; NLA env has been migrated to Sunflower ICs analyze selected users' permissions |
| 13 | Week 12 | 8/11-8/15 | Cornell env is ready. Test Cornell (both strategies) Finish setting up env for NLA
|
| 14 | Week 13 | 8/18-8/22 | Remaining non-critical defects finished NLA and Cornell testing finished |
| 15 | Week 14 (may not be needed) | 8/25 - 8/29 | Wrap up |