Co-authored-by: Chris Colvard <[email protected]>

Co-authored-by: Chris Colvard <[email protected]>

add basic required metadata to the pcdm collection form

Add administrative set form with minimal metadata

add config for setting admin set model

existing collections indexed as `'Collection'` and those created with `Wings`
should still turn up in queries.

probably we should be using the indexed `generic_type` for these filters instead
of a list of models, but this keeps compatibility until we can work that out.

updates metadata in the model and indexer

For some reason there were two spec files testing `Hyrax::AdministrativeSetIndexer`.  One in `hyrax/administrative_set_indexer_spec.rb`.  The other in `hyrax/valkyrie_administrative_set_indexer_spec.rb`.  The tests are the same in both spec files.  I removed the one starting with `valkyrie` because the other one follows the normal naming conventions.

we want these stubs to apply for whatever collection class is in use in the test
suite.

this partial has apparently never resolved properly; it's test was stubbed.

this fixes the reference and forces the template to resolve to pass the view spec

this presenter method was previously deprecated in favor of a helper. it looks
like this view got missed in that update.

setup these tests with valkyrie.

update these expectations to be sensitive to current model class filter
considerations. use the Valkyrie test class `Monograph` as the dummy work class,
since `GenericWork` is likely to be removed from the test app at some point.

this is a case where we are doing a whole collection lookup just to then pass
the id to the collaborator service. skip this and save the DB round trip.

`Dashboard::CollectionsController` tests still have quite a few hard-coded class
expectations. this loosens a few of them up.

we want to be able to take actions (e.g. to log, or send timeseries data), when
a collection changes its membership. add a hook for this.

when using a collection class other than `::Collection`, apply Hyrax's
curation_concern permissions. (e.g. this allows `#create`).

map `Hyrax::PcdmCollection` to `Hyrax::Forms::PcdmCollectionForm` for the
factory method's purposes.

`Dashboard::CollectionsController#create` has some behavior to avoid CanCan's
load_resource hook. the reasons for avoiding this are a bit opaque, but we
definitely don't want to carry this forward. disabling it immediately does
actually fail some tests, so instead limit the skip to cases where an
ActiveFedora collection class is in use.

if a ChangeSet has a `#collection_type_gid` value, never override it with the
default.

Valkyrie models don't index automatically on save, so setting a "re-index
extent" on the model doesn't make much sense.

it's honestly not clear to me that this line does anything at all. the
collection doesn't appear to be saved (or indexed) as part of this controller's
logic.

whatever the case, it turns out that just not failing on this assignment makes
this controller's unit tests pass. we'll definitely want to look closer at
it, since the controller is doing `load_and_authorize_resource` on the whole
collection just to then pass through the id to a collaborator---do we need to
load the object, or just authorize based on id and move on?

this actor won't be updated for compatibility with Valkyrie-based collection
models. skip its tests in the case that Valkyrie is in use for Collection.

these specs stubbed ActiveFedora in unnecessary places, and just generally had
convoluted setup and expectations (one test memoized an empty array, used a
before block to populate it, and then checked its contents as the only
expectation!).

don't exercise code under test in `subject` or `before`.

query collection from Valkyrie and use it to handle PermissionsCreateService
logic.

these are just extra test setup and can be squashed down.

this indirection makes tests less readable! use `subject` for the object under
test, and exercise code in the individual examples.

adds Valkyrie handling for `#create`, `#update` and `#destroy` actions on
`Dashboard::CollectionsController`.

these implementations are a bit simple, but pass all the controller level test
for these actions (the `#files` action remains unhandled). this handling is
invoked whenever `@collection` is a `Valkyrie::Resource`. the easiest way to
achieve this is to set `Hyrax.config.collection_model` to a Valkyrie model class
name.

via the Hyrax.config.collection_class

Add read only mode feature

extend Collection abilities to allow checking for `:deposit` access by id (we
use the id anyway, so this avoids looking up a Collection model and then
retrieving its id).

extend `NestCollectionsForm` to support passing in ids for "parent" and "child"
collections. the goal of this refactor is to make it easy for the controller to
pass through params. since the user specifies collections by id, using
`ActionController::Parameters` as the arguments to the form greatly reduces form
building logic in the controller.

lastly, refactor the controller itself to use this new approach. this reveals a
whole lot of duplicate code, which can be further refactored in later work.

move authorization logic into controller actions (this really doesn't belong in
anything named "build"), and then extract now duplicated form initialization
logic into a single lazy-accessor method.

deprecate the old methods since they're likely used in overridden actions by
downstream apps (in general, we try to treat even "private" controller methods
as public API, because of the prevelance of monkey patching).

reduce longlines, reduce duplication of parameters, rearrange.

rather than forcing a lookup of the collection type, extract the
`URI::GID::model_id`. this is more general, since not all models will have
lookup logic in `collection_id`, but the Collection contract guarantees a
`#collection_type_gid` that will return a valid GlobalID formatted string.

If `Collection` does not exist in the application, then ability checks that reference that class raise an exception.  Since some code has been converted to use `Hyrax::PcdmCollection` .

NOTE: Tests were refactored to have a single test for all `to be_able_to` and one for all `not_to be_able_to`.  They were originally written this way.  The refactor in PR #5148 was an attempt to get specificity in failure reporting.  But as it is uncommon for these tests to fail and the tests run in 23s instead of 3m in the single test approach, it seems prudent to use the original approach for testing.

…o collection on create

Co-authored-by: tamsin johnson <[email protected]>

Co-authored-by: tamsin johnson <[email protected]>

…admin sets

This service is flexible enough to handle both valkyrie and active fedora collections and administrative sets.

NOTE: Most of the changes in this file is are related to indentation changes for the refactor to use `class << self` since all methods are class methods.

The only substantive change is the way that `collection_type` is set in `#create_default`

One other change is that `#create_default` said it returns a PermissionTemplate, but it was returning the results of `#reset_access_controls_for` which returns a `Boolean`.  Updated the method to actually return the permission template.

… process in admin set’s create service

this form should only be used if an ActiveFedora `Collection` model is
used. otherwise simply skip the specs in CI.

this whole module requires type checking on Wings, so just don't include it if
Wings is disabled.

we want the collection form data to be the same regardless of the model
used. ActiveModel naming is the right place to handle this.

skip CollectionForm specs if ActiveFedora isn't used for Collections

add param_key and plural to `Hyrax::CollectionName`

skip ActiveFedora indexing if Wings is disabled

the tests for this controller were not sufficiently granular to make debugging
easy. i encountered this working on Collection support for Valkyrie (where these
tests are failing seemingly due to #5214). it took me some time to understand
what was going wrong, so i wanted to make the tests clearer by following the
one-expectation-per-spec-block pattern.

even when using Valkyrie (and Hyrax::PcdmCollection), we expect Wings to index
to the ActiveFedora Solr core using `::Collection`. for this reason, searches
should continue to resolve legacy `::Collection` references for the moment.

extract dependency on Form level `#thumbnail_title` methods to a helper, avoid
NoMethodError that breaks the entire page if this method isn't present in an
application's form implementation.

using `#collection?` on the `hydra_model` turns out to be useless, since
`hydra_model` is actually a Class, not a model instance.

instead just respect whatever model is configured. trust that
`SolrDocument#hydra_model` will get resolved to the configured class.

create a topic for tracking file downloads.

`PermissionTemplateAccessesController` decides where to redirect based on the
SolrDocument's model type, but falls through to a 204 No Content if the
SolrDocument isn't sure what it is.

this is probably okay for successes, even if it's a bit user unfriendly, but is
a serious problem for failures where we don't want to be returning a Successful
response status code!

even for successes, it's hard to see the downside of redirecting to the
collection edit path by default. can't be worse than redirecting to a blank
page.

Avoids an issue where setting Valkyrie to `’< 3.0’` allows Valkyrie to resolve to `3.0.0.beta1`.

Co-authored-by: tamsin johnson <[email protected]>

add @see documentation to `Hyrax::Controller#transactions`

extract duplicated setup to a shared `before` block. remove unused setup.

This is in prep of the next step that will be able to create a `Hyrax::AdministrativeSet`.

Since this method doesn’t do any of the real work, only check that it passes through.  The real work will be tested in the method that performs the work.

Since this method doesn’t do any of the real work, only check that it passes through.  The real work will be tested in the method that performs the work.

update comments to reference `Hyrax::AdminstrativeSets` instead of `AdminSet`

`.call` and `#create` methods return Boolean and may hide runtime errors.  Instead, use `.call!` and `#create!` respectively.

downstream apps can provide solr config! respect that when its in use.

Integrated the changes from PR #5213 over the service updates in PR #5225.

respect hyrax index adapter config

simplify _relationships partial view spec

update specs to ensure the correct models are included in the search:

  - always include `Collection`,
  - include configured collection model name,
  - include registered curationconcerns

should the implementation be updated to search using the indexed generic type?

test AdminAdminSetMemberSearchBuilder for collection search

When using the postgres adapter, the following error happens when creating collection permissions.

```
NameError: uninitialized constant PermissionTemplate
/Users/elr37/Documents/__DEVELOPMENT__/Samvera/TEST/nurax-pg/vendor/bundle/ruby/2.7.0/bundler/gems/hyrax-8c6b1d32e8a1/app/services/hyrax/collections/permissions_create_service.rb:17:in `create_default'
```

This happened because the permission template was referenced without the module…
```
PermissionTemplate.create!
```

The fix is to reference permission template with the module…
```
Hyrax::PermissionTemplate.create!
```

include module for PermissionTemplate

…e admin set

…n admin_set

add depositor to pcdm collection indexer

Fix admin set valkyrie create

When `disable_wings=true`, the `Wings` constant is not defined.  As a result, you cannot check directly to see if the metadata adapter is “Wings::Valkyrie::MetadataAdapter”.  This check results in a “NameError”.  If we check for `disable_wings` first, then it avoids the check of the metadata adapter.

Allow work form to display when wings is disabled

the mistaken namespacing of `::SolrDocument` led to mistakenly restricted
authentication on SolrDocument download. where `can?(:download, id)` had the
expected behavior `can?(:download, solr_document)` gave `false` in all cases.

this bug in `Ability` had been present for some time. beginning in Hyrax 3.1.0,
we rely on this permission to be correct, so the visible in that release.

this issue was reported as #5241.

fix bug in Hyrax::Ability#download_permissions SolrDocument handling

remove unused stubs; move other stubs closer to where they're needed; reduce
indirection (e.g. exercise code under test in `it`, not `before` blocks).