We want to create a Gemified, pluggable version of the Community and Collection model we need for the Hydranorth Institutional Repository, so that we can make it easy for other institutions to plug our model into Sufia and leverage what we've done. We also hope that this will reduce the effort required to keep our changes up-to-date with stock Sufia versions going forward.
What Will 'Done' Look Like?
When this epic is completed, we want the following deliverables to exist:
A 'CollectionNorth' gem that implements our Collection/Community model in the default Sufia theme
Subclasses implementing that model in our Hydranorth Institutional Repository, with any view overrides necessary to adapt the CollectionNorth gem's views to our theme.
A comprehensive set of tests of Collection and Community behaviour in the CollectionNorth gem, and tests for any Hydranorth-specific changes in the Hydranorth application.
What's It Going to Take?
Roll-up Estimate:
Resources:
Rough Timeline:
What's Out of Scope?
Moving existing Collection and Community data over to the new model. That's being tracked in a separate Epic (#1105).
Admin functionality (maybe? see Questions We Still Have)
fancier mechanisms for enforcing different official vs personal collection policies on "families" of collections -- let's save that for a round 2 of collection work
What Are The Deal Breakers?
Getting the modeling of nested collections wrong
Not worrying about performance early and often (missing necessary fields for Communities in Solr, for instance)
Not planning for nesting of collections
Not planning for putting Works in multiple collections (should come for free in PCDM, however)
Questions We Still Have
Are we doing collection admin here, or in the admin gem?
Remove ability of users to create collections in CollectionNorth gem, or in Hydranorth?
Remove avatars/descriptions from collections in CollectionNorth gem, or in Hydranorth?
It sounds like we're leaning towards centralizing this logic in an Admin gem
What does an 'official' collection/community imply, are we missing any work below to implement that? (this is an artifact of inheriting personal collections, all "admin" collections/communities are official, but we can see use cases for personal collections down the road in eg. Peel collections)
We want to remove the ability for regular users to create collections, correct? Is there a more elegant way to achieve that than the one proposed in ticket #?? below?
Do we need input from the metadata team on doing Collection nesting in PCDM? (PCDM already models this, although sufia7 doesn't allow this (yet?))
Behaviour of Community/Collection display for Works. What do we do if a Work is in 2 different collections in the same community? Does that manifest as displaying the community name twice or do we need logic to catch that? (Breadcrumbs might be an elegant side-step of this problem)
How Are We Getting There?
Infrastructure Work (43)
[x] Create repositories & engine/rails projects for "CollectionNorth" and "Hydranorth7" (#1145)
[x] setup rspec & rubocop (#1146)
[ ] Ruby 2.2 upgrade (Estimate: 1 (on our side)) (Peter to Create)
[x] Test data for collection/solr join behaviour for #1126 (#1154)
[x] jenkins/travis investigation setup (#1151)
[x] dedicated performance testing on workstation (#1152)
[ ] ActiveJob/Queueing investigation (#1153)
[ ] TODO any other infrastructure needed?
this will connect with the broader DI storage architecture discussion (December 2016)
Location: CollectionsNorth gem
Data Model: (32)
[x] Plan a data model for Collection nesting in PCDM (#1122)
[x] Investigate existing sufia 7 features vs what we have in Hydranorth to figure out the specific behaviours to implement here. (#1148)
[ ] Create a CollectionBehaviour module implementing said data model (#1123)
[x] add is_official logic to the CollectionBehaviour module (#1123)
[x] Gather requirements for data model for Communities (#1124)
[ ] Create CommunityBehaviour module extending the CollectionBehaviour module and implementing this model (#1125)
[ ] add hasCommunity logic to the CollectionBehaviour module (#1125)
[ ] Create a Collection Indexing Service subclassing ActiveFedora::IndexingService (#1126)
[ ] Alter CollectionBehaviour and CommunityBehaviour modules to export this class as their indexer (#1126)
Controllers and Views: (59 + investigation)
[ ] Multilevel faceting of collection and community nesting (#1149)
[ ] Indexing thereof: (#1149)
[ ] Overide Works and Catalog partials to display Collections AND Communities titles associated with work (#1127)
[ ] Remove Image from Collection Partials (they are community only) (#1128)
[ ] Create interface for nesting, controlling official, controlling community, avatars on Communities, descs on Communities
[ ] Admin Permissions (ties into Admin gem?) Moving to Admin Gem
[ ] Create correct implementation of locking attributes to only Admin (currently missing) Moving to Admin Gem
[ ] Remove all ability of regular users to create Collections/Communities () Moving to Admin Gem
[ ] Create Routes for edit/update actions (#1129)
[ ] Create Community Controller behaviour w/ logic for update (#1129)
[ ] Create Form for editing these attributes (#1129)
[x] Modify interface for editing Collections (#1130) don't need this IF we're not doing user collections at all
[ ] Adding collections to community interface (#1150)
[ ] Faceted Collection Display to render nested Collections (#1139)
[ ] Change query default result counts to allow for large collections without truncation (#1131)
[ ] Create a CommunityControllerBehaviour module in CollectionNorth (#1132)
[ ] Create Routes for the index page in CollectionNorth (#1132)
[ ] Create an index view for Communities in CollectionNorth (#1132)
[ ] Override default Deposit form (#1133)
[ ] Create Partial for Community & nested Collection Selection (#1133)
[ ] Create new JavaScript file to update the Collection dropdown when the Community is changed (#1133)
[ ] Include tag for new JS file in the Community/Collection partial (#1133)
[ ] Insert partial render into the overridden Works deposit form (#1133)
[ ] Alter validations to enforce selection of Community (but not a collection) by users when submitting the deposit form (#1133)
[ ] Override item edit form (#1134)
[ ] include partial from #1133 in item edit form (#1134)
[ ] Override batch edit form (#1135)
[ ] include partial from #1133 in batch edit form (#1135) Is this necessary? Does this exist in Sufia 7?
[ ] TESTS
Location: Hydranorth7 (20)
[ ] Create Collection Model, include CollectionNorth::Collection functionality (#1140)
[ ] Create Community Model, include CollectionNorth::Community functionality (#1140)
[ ] Create Collection Controller for CollectionNorth::CollectionControllerBehaviour (#1141)
[ ] Create Community Controller for CollectionNorth::CommunityControllerBehaviour (#1132)
[ ] Adapt Views to Hydranorth theme (#1142)
[ ] porting the CSS from current Hydranorth over (#1142)
[ ] port current homepage over (but fix the fact that it's all implemented in a layout for some reason) (#1142)
[ ] port the various themed error pages over (404, 500, etc). (#1142)
[ ] Profile and identify performance regressions (#1143)
[ ] measure Collection show (#1143)
[ ] Community show (#1143)
[ ] Item show community/collection/item edit pages (#1143)
Why Are We Here?
We want to create a Gemified, pluggable version of the Community and Collection model we need for the Hydranorth Institutional Repository, so that we can make it easy for other institutions to plug our model into Sufia and leverage what we've done. We also hope that this will reduce the effort required to keep our changes up-to-date with stock Sufia versions going forward.
What Will 'Done' Look Like?
When this epic is completed, we want the following deliverables to exist:
What's It Going to Take?
Roll-up Estimate: Resources: Rough Timeline:
What's Out of Scope?
What Are The Deal Breakers?
Questions We Still Have
How Are We Getting There?
Infrastructure Work (43)
Location: CollectionsNorth gem
Data Model: (32)
Controllers and Views: (59 + investigation)
Location: Hydranorth7 (20)