samvera / hyku Goto Github PK

Check where UploadedFiles live on the filesystem, and also where CarrierWave puts things (like user avatars) and make sure we won't run into conflicts.

As a depositor, when I upload a single photograph as a new work, it should be available via the IIIF Presentation API. See the proposed model-to-IIIF mapping. Note that we do not currently use Parts, so we're lacking a Canvas in the current mapping. If helpful, seek advice from @no-reply and @tpendragon and others.

Tentatively scheduled for sprint 6. Blocked by #112.

Create a data model in Sufia based on Curation Concerns to enable a depositor to upload an image-based work, along the lines that have been described in user scenarios produced by the Design Team

This gets confusing:

Pull the metadata from the MODS that is within the bags.

With #53, set the solr url for upstream dependencies at runtime using the Site.instance.solr_url (or whatever) configuration. Solr is current configured for a couple different dependencies:

• Blacklight
• ActiveFedora
• ??

If a FileSet is not public, then any requests to it's files via IIIF should be protected by hydra access controls.

(Possibly in a background job?):

• Drop the tenant database
• Delete the Solr collection
• Clean up Fedora

If I didn't know any better, I'd think that Account name was for my personal name rather than my site name. Can we do something to clarify?

When running in development and in tests, we want to use Solr in SolrCloud mode.

• add any necessary settings to the solr configuration to support SolrCloud
• enable SolrCloud mode with the embedded zookeeper

Could include:

• Sufia config settings
• Discovery (facets, displayed fields; see Spotlight)
• Application Appearance (UI templating)

Or, if we're feeling clever, we should create a UUID for each Site, and use that identifier to connect it to a solr collection.

Supersedes #5.

When indexing a document into Solr, add relevant site information (say, a unique identifier) to the generated solr document. This should allow us to support administrative cross-site querying and other admininstrative functions.

Blocked by #113.

Package universal viewer with hybox.
Have a link from the show page that opens UV.
Do what plum does.

(Removed in #99, as many upstream migrations are not strong_migrations friendly)

E.g., find items deposited by a certain depositor

https://github.com/projecthydra-labs/hybox/blob/master/LICENSE#L189 reads:

Copyright {yyyy} {name of copyright owner}

Presumably we want to fill in the blanks. Who is copyright owner?

Apartment has activejob support:

https://github.com/influitive/apartment-activejob

We need to extend that to also switch Fedora + Solr connections

Building on the work done in #74, make the about page content block editable. This could be done in sufia. (remove the in-place editing blocks)

Ref #164

The user activity stream shows cross-tenant activity for users that happen to share the same database id. Possibly look into https://github.com/resque/redis-namespace?

We could also consider refactoring Sufia's activity streams to not use Redis, maybe:

• https://github.com/chaps-io/public_activity
• https://github.com/ledermann/unread

Create a data model in Sufia based on Curation Concerns that supports multi-file works for Hybox if the existing model is insufficient in some way

Each tenant needs configuration to point at different Solr configurations.

• add a solr_url (❓ ) field to the Account model
• delegate the field via the Site singleton
• initially auto-populate the configuration with the current, global solr url
• expose the url in appropriate admin interfaces (Account#show, Site#edit ?) for demo purposes

We should provide audit and change tracking to Account attributes, allowing administrators to view changes and restore versions or deleted accounts.

In spotlight, we're using the paper_trail gem to track model changes, and may be relevant here as well.

• Solr
• Fedora

Tentatively scheduled for sprint 6.

The admin role is intended to be scoped to administrative actions within a given site/tenant.

For reporting or other administration, we will also need a superadmin role with additional, application-wide privileges. In other applications, we've called this role a superadmin.

• upload the solr configuration into SolrCloud with a hard-coded configset name
• add default configuration to config/settings.yml to point at the hard-coded configset name

The admin role currently gives global admin privileges, including over all Account information. We should restrict the admin role to only managing the Account for their current site. We may want to restrict the site admin from being able to the destroy the Account too.

The superadmin role (#65) should have global privileges over all Account data, including the ability to destroy the model.

See: 2bfbcf1