:bug: Batch add and valkyrized works are incompatible

[ShanaLMoore]

Summary

Refactor Batch Add (Create) to be fully Valkyrie-based and generate Step 2 (common metadata) dynamically from the selected work type. For Bulk Change (Edit), remove metadata editing and support permissions and visibility only.

Acceptance Criteria

GIVEN an authenticated user has permission to create works AND the Batch Upload feature is enabled for the tenant in their features settings WHEN the user

Implementation notes

• [ ] Batch Add (Create)

  • [ ] Type selection is required before Step 2.

  • [ ] Step 1: upload files + per-file Title and Resource Type (options reflect selected work type).

  • [ ] Step 2: fields come from the selected work type’s Valkyrie form/changeset (or profile):

    • [ ] Only valid terms for that type are shown.
    • [ ] Required fields are indicated and enforced; server-side validation blocks submission with inline errors.

  • [ ] Batch create makes one work per file, attaches files, applies Step-1 (Title/Resource Type) + Step-2 common metadata.

  • [ ] No reliance on the fake ActiveFedora form; compatible with Hyrax 6.1/6.2 (covered by tests).

  • [ ] Error states: missing required fields block submission; no phantom validations for fields not in schema.

• [ ] Bulk Change (Edit) — Permissions & Visibility only

  • [ ] UI shows Permissions and Visibility controls only; all metadata fields are removed/hidden.

  • [ ] Server accepts and applies only:

    • [ ] Permissions (sharing/ACLs as currently supported).
    • [ ] Visibility (open, authenticated, restricted). (Embargo/lease management is out of scope for this ticket.)

  • [ ] Mixed work-type selection is allowed (no type gating needed).

  • [ ] Submitting any metadata params via the request is ignored and not applied (test coverage included).

  • [ ] Success and error messaging reflect the limited scope (“Bulk Edit updates permissions and visibility only”).

Screenshots or Video

What to capture

• Batch Add:

  • Type picker gating “Next” until a type is selected.
  • Step 2 for two distinct work types showing different fields.
  • Inline validation on a required field.
  • Success summary: N works created with files attached.

• Bulk Change (Edit):

  • Updated panel showing Permissions & Visibility only.
  • Network/dev-tools example showing metadata params ignored by server.

Testing Instructions

• Setup: Ensure two work types with different required fields (e.g., ImageWork requires creator + date_created; GenericWork requires creator). If using flexible metadata, configure distinct profiles.

Batch Add

1. Choose ImageWork, upload 3 files, set Titles/Resource Types → Step 2 → fill required fields → submit. Expect: 3 valid works, files attached, required metadata present.
2. Choose GenericWork, omit a required field → submit. Expect: Blocked with inline error; success after fixing.
3. Confirm Step 2 fields differ by work type and match each type’s schema/profile.
4. Run above flows under 6.1 and 6.2.

Bulk Change (Permissions & Visibility only)

1. Select multiple works (mixed types) → Bulk Edit. Expect: Only Permissions and Visibility controls are present.
2. Change visibility (e.g., to authenticated) and update a permission rule → submit. Expect: All selected works reflect new visibility and permissions.
3. Attempt to POST metadata fields via dev tools. Expect: Server ignores metadata; only permissions/visibility changes persist (assert in tests).

Sample Files

• image_a.jpg, image_b.jpg, image_c.jpg
• doc_a.pdf, doc_b.pdf

Notes

• Why: Current Batch Add uses a fake AF form with fixed terms that ignore the selected type, causing Valkyrie validations to fail (especially on 6.2).

• Approach (Batch Add): Instantiate the selected work type’s Valkyrie form/changeset (and/or profile) to derive terms, required fields, strong params, and validations. Keep Step 1 minimal; apply Step 2 common metadata to each created work.

• Decision (Bulk Change): Scope Bulk Change to permissions + visibility only to avoid cross-type schema collisions and reduce maintenance.

• Follow-ups (document, not in scope):

  • Option A (recommended to keep): Continue permissions + visibility only.
  • Option B (alternate): JS restriction to a single work type selection, then render a type-specific metadata edit form (valkyrized). Lower ROI given usage patterns; consider only if needs change.

[ShanaLMoore]

Notes from LaRita:

hmmm I’d have to fire it up to remember what the issues are specifically. I will try to explain a bit here from what I remember. If this makes some sense to you, I can add it to the issue. If not, ask questions!

There are a couple problems, centering around how the form works. First of all, if I remember right, there are some methods that aren’t defined for the form. But primarily it’s the overall design that’s the problem.

Add works with a fake ActiveFedora object and a form based on that object. When you select to add a batch, the popup comes up asking what type of object, but it doesn’t use that to create the form for that object… it still shows the fake form. On the first tab, you upload your files, and set the titles and resource type. New works are created for each of these files using the titles and resource types. These 3 pieces of info are the only things which vary between the works. On the second tab, you fill in all of the other common metadata which is used on each of the works you are creating. There are one or two more tabs for common permissions, etc.

Once the attributes are available, we create a new object of the specified type with the given attributes. The problem here is with required terms. With ActiveFedora we could still somehow get invalid record data through (we did it in Bulkrax and it was done here as well). With Valkyrie, the forms HAVE to have all of the required fields and pass validation. Since the fake object that we use only require title and resource_type, and the required terms may not even be part of the list of terms on the fake object, the validation fails.

It does work in 6.1 but not for all work types because of the required terms on the object not being in the list of terms it uses for the fake form. But 6.2 introduced changes in the methods, as well as the complexity of unpredictable metadata, which makes changes a necessity.

First of all, we MUST valkyrize the process. This would ensure that the form responds to the methods needed, and only includes valid metadata terms. This involves a significant rewrite of the very convoluted process that is used right now. We need to use the selected object type to build the form info for the second tab. This way the appropriate terms can be required and validated, and we aren’t using a fixed list of terms which may be invalid.

Additional note: The issue with change is similar to the above, but the reason it is NOT broken for 6.2 is because 1) the form had previously been valkyrized so it mostly worked and I just had to rewrite a bit because of lazy migration, and 2) if we are editing works, they should already have the required terms filled in. It still breaks if the editable terms are not on all of the work types so to get it working for pals, I had to override and remove a few of the terms.

Rob’s idea to make change more useful was to use javascript on the checkboxes, so once you select one work to bulk edit, you can ONLY select others of that same work type. Then base the edit form on that work type’s metadata. But once we found out that editing anything beyond permissions is very rare, we didn’t pursue any additional changes to the change process.

[ShanaLMoore]

TL;DR:

• Root cause: Batch Add uses a fake ActiveFedora form that ignores the user’s selected work type, so Step 2 shows a fixed field list.
• Impact: Under Valkyrie (esp. 6.2), forms must include all required fields for the chosen type. The fake form only has title + resource_type, so validations fail; 6.1 worked only for some types.
• Why AF seemed okay: AF allowed invalid data to slip through; Valkyrie’s changesets don’t.
• Fix (required): Valkyrize Batch Add. After type selection, build Step 2 from that type’s Valkyrie form/changeset (or profile), showing only valid terms and enforcing required fields. Remove the fake AF object.
• Bulk Change status: Already mostly valkyrized in 6.2 and works because existing works usually have required terms. Still brittle if editable terms differ by type.
• Optional enhancement (low priority): In Bulk Change, limit selection to one work type via JS and generate the edit form for that type. Editing beyond permissions is rare, so this wasn’t pursued.

[SixtyGrit]

Based on feedback from PALs, this would be a low-priority relative to general bulkrax improvements, and reducing the scope of the Batch Edit works function to be permissions and visibility only. cc: @ndroark @ShanaLMoore @orangewolf