Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move Bulkrax field mappings to Hyku #2389

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

bkiahstroud
Copy link
Collaborator

Follow up to:

A recent Hyku feature introduced the ability to configure Bulkrax field mappings on a per-tenant basis. It also introduced a bug that impacted existing Hyku applications who had custom field mappings. Since the feature fell back on Bulkrax's default field mappings if an Account hadn't explicitly set their own, the existing field mapping customizations in the Bulkrax initializer were ignored.

To solve that issue, as well as the question of "what if I want all my tenants to have the same field mappings, but don't want to customize them all by hand?", this commit introduces the idea of a set of default field mappings at the Hyku application level.

Caution

This is a breaking change

Existing Hyku applications with custom Bulkrax field mappings will need to move them from their config/initializers/bulkrax.rb to Hyku#default_bulkrax_field_mappings in config/application.rb

Now, when Bulkrax looks for field mappings, it will discover them in this order (depending on presence):

Account setting? -> Hyku defaults? -> Bulkrax defaults

There are a couple reasons why I decided to put this in the Hyku module instead of just using Hyku's Bulkrax initializer:

  1. Since they're Hyku's defaults, it makes sense to denote them as such semantically and conceptually
  2. Since the ultimate fallback is Bulkrax's default field mappings, it makes sense not to alter the field mappings that Bulkrax "manages" with this feature
  3. When adding hyku_knapsack into the mix, their often ends up being three separate Bulkrax config files (the knapsack's config/initializers/bulkrax.rb, Hyku's config/initializers/bulkrax.rb, and Bulkrax's lib/bulkrax.rb). This gets very muddy very quickly with how knapsack works technically

@samvera/hyku-code-reviewers

A recent Hyku feature introduced the ability to configure Bulkrax field
mappings on a per-tenant basis. It also introduced a bug that impacted
existing Hyku applications who had custom field mappings. Since the
feature fell back on Bulkrax's default field mappings if an Account
hadn't explicitly set their own, the existing field mapping
customizations in the Bulkrax initializer were ignored.

To solve that issue, as well as the question of "what if I want all my
tenants to have the same field mappings, but don't want to customize
them all by hand?", this commit introduces the idea of a set of default
field mappings at the Hyku application level.

This means that when Bulkrax looks for field mappings, it will discover
them in this order (depending on presence):

Account setting? -> Hyku defaults? -> Bulkrax defaults

There are a couple reasons why I decided to put this in the Hyku module
instead of just using Hyku's Bulkrax initializer:
1. Since they're Hyku's defaults, it makes sense to denote them as such
   semantically and conceptually
2. Since the ultimate fallback is Bulkrax's default field mappings, it
   makes sense not to alter the field mappings that Bulkrax "manages"
   with this feature
3. When adding hyku_knapsack into the mix, their often ends up being
   three separate Bulkrax config files (the knapsack's
   config/initializers/bulkrax.rb, Hyku's
   config/initializers/bulkrax.rb, and Bulkrax's lib/bulkrax.rb). This
   gets very muddy very quickly with how knapsack works technically

Ref:
- #2384
@bkiahstroud bkiahstroud added the major-ver for release notes label Nov 23, 2024
Copy link

github-actions bot commented Nov 23, 2024

Test Results

    3 files  ±0      3 suites  ±0   18m 41s ⏱️ +18s
2 047 tests ±0  1 996 ✅ ±0  50 💤 ±0  1 ❌ ±0 
2 074 runs  ±0  2 021 ✅ ±0  52 💤 ±0  1 ❌ ±0 

For more details on these failures, see this check.

Results for commit ff87a91. ± Comparison against base commit 571c2de.

This pull request removes 42 and adds 42 tests. Note that renamed tests count towards both.
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor Etd permissions is expected not to be able to destroy 1585adcb-6113-45fd-b7ed-ea947c73a71d
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor Etd permissions is expected not to be able to edit 035d082f-9152-4b56-8241-701432d748f4
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor Etd permissions is expected not to be able to read e2565459-4945-48d8-a282-df2b26200af2
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor Etd permissions is expected not to be able to update a8e985cd-3e60-486e-8821-8b6c7e9a531d
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor FileSet permissions is expected not to be able to destroy 506d33f5-d061-4fd0-b076-128d76126a5b
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor FileSet permissions is expected not to be able to edit 759c8043-8ac3-4aa8-b21d-45f23c40ecf0
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor FileSet permissions is expected not to be able to read faf44d9b-7ac9-43e4-9bbe-399c739b6944
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor FileSet permissions is expected not to be able to update e3045cf0-3795-4c9d-83c3-d39e6f5fcc2a
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor GenericWork permissions is expected not to be able to destroy 4bbf76e6-e710-4075-bedf-10ce38bed194
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor GenericWork permissions is expected not to be able to edit 51795746-9b9a-466c-83f0-439d63704ceb
…
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor Etd permissions is expected not to be able to destroy 237b080d-4ac6-443c-ae20-1bd9ba435f0a
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor Etd permissions is expected not to be able to edit a11e80d0-224f-4b52-953c-c9c86916af05
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor Etd permissions is expected not to be able to read 652e2848-0f54-4838-af86-183b26620a69
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor Etd permissions is expected not to be able to update b2c1c656-eac0-44c3-83fb-1a40fb19889d
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor FileSet permissions is expected not to be able to destroy 3abffeaa-9876-4c88-9a85-84fd307fbbc8
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor FileSet permissions is expected not to be able to edit a609bc50-6aa5-4978-b78a-f231fed2abce
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor FileSet permissions is expected not to be able to read 7ecedbd6-4900-4f7a-89bb-ce32b123618f
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor FileSet permissions is expected not to be able to update e97c6fd8-ec3f-4e5c-a56c-a9153e0a4499
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor GenericWork permissions is expected not to be able to destroy ef345bf1-35d0-484d-a826-1c4651422d7e
spec.abilities.work_ability_spec ‑ Hyrax::Ability::WorkAbility when work depositor GenericWork permissions is expected not to be able to edit 8e2a9293-69c5-4c3f-998f-764cd6da0f22
…

♻️ This comment has been updated with latest results.

This can be used by a hyku_knapsack app initializer to override the
default Hyku application field mappings
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
major-ver for release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant