A MIRA replacement running on Hyrax 2.0.
- MySQL
- Redis
- Path to FITS in the Hyrax initializer
- sidekiq as queue adapter in application.rb:
config.active_job.queue_adapter = :sidekiq
Get started by cloning the repository, installing the dependencies, and ensuring the test suite runs:
git clone https://github.com/curationexperts/epigaea.git
cd epigaea
bundle install
bundle exec sidekiq -d -l tmp/sidekiq.log
# start each of the next services in their own terminal session
bundle exec rake hydra:server
bundle exec rake hydra:test_server
#back in your main terminal session
bundle exec rails db:setup
bundle exec rake spec
First, you'll need to start your development server and create a new user.
bundle exec rails c
> u = User.create(email: 'admin@example.org', display_name: 'Admin, Example', password: 'password')
> u.add_role('admin')
> exit
Now you should be able to login as admin@example.org
with access to the administator dashboard.
MIRA supports a number of configurable deposit types. A seed configuration is checked into the repository at
config/deposit_type_seed.csv
. Load this seed file by running the following rake task:
bundle exec rake import:deposit_types[config/deposit_type_seed.csv]
# then enter `yes` to complete the import
If you wish to make changes to the seeds, use the "Manage Self Deposit Types" option from the administrator dashboard. Make any changes you want, export the configuration using the "Export Deposit Type Data" link at the bottom of the "Manage Deposit Types" view, and then check the updated deposit type configuration CSV file into the repository.
If you need to re-create derivatives, use these rake tasks:
- One at a time, by id:
RAILS_ENV=production bundle exec rake derivatives:recreate_by_id[2801pg32c]
- Re-create derivatives for all PDF objects:
RAILS_ENV=production bundle exec rake derivatives:recreate_all_pdfs
When running this application in production, you can point monitoring systems at /okcomputer/all
to
verify that system integrations are working as expected. Checking for the absence of the word FAILURE
would work. If everything is working as expected, you should see:
batch_sidekiq_queue_latency: PASSED Sidekiq queue 'batch' latency at reasonable level (0) (0s)
database: PASSED Schema version: 20171009170516 (0s)
default: PASSED Application is running (0s)
default_sidekiq_queue_latency: PASSED Sidekiq queue 'default' latency at reasonable level (0) (0s)
handle_sidekiq_queue_latency: PASSED Sidekiq queue 'handle' latency at reasonable level (0) (0s)
smtp: PASSED SMTP connection working (1s)
You can also check individual systems by adding their name to the end of the okcomputer url, e.g., /okcomputer/smtp
.
See okcomputer on github for more configuration options.
Hyrax has some built-in integration with Google analytics. Instructions for configuration are in the Hyrax Management Guide. To track usage using google analytics:
- Follow the abovementioned guide and set up a google analytics account. Take note of the analytics tracking id you are assigned and the json key you are prompted to download.
- Put the .json key in
/opt/epigaea/shared/config
and call itepigaea_private_key.json
- Populate the
.env.production
file on the production server with the relevant values fromepigaea_private_key.json
:
export GOOGLE_ANALYTICS_ID=UA-000000000-1
export GOOGLE_OAUTH_APP_NAME=epigaea (make up any value here)
export GOOGLE_OAUTH_APP_VERSION=2.0 (make up any value here)
export GOOGLE_OAUTH_PRIVATE_KEY_PATH=/opt/epigaea/config/epigaea_private_key.json
export GOOGLE_OAUTH_PRIVATE_KEY_SECRET=[key from your .json file]
export GOOGLE_OAUTH_CLIENT_EMAIL=epigaea@whatever.gserviceaccount.com (from your .json file)
NOTE The instructions above will allow you to track usage on the google analytics website. Integration into the Hyrax admin dashboard has not yet been completed but is expected eventually. See Hyrax Analytics and Usage Statistics for more details.
All notifications use Hyrax::MessengerService
, which in turn uses Mailboxer.
Mailboxer can be configured to send notifications by email. You can configure it to
use a different SMTP system by defining the appropriate values in a .env.production
file.
Required variables are:
export ACTION_MAILER_SMTP_DELIVERY_METHOD=smtp
export ACTION_MAILER_HOST=localhost
export ACTION_MAILER_SMTP_ADDRESS=**YOUR DATA HERE**
export ACTION_MAILER_PORT=**YOUR DATA HERE**
export ACTION_MAILER_USER_NAME=**YOUR DATA HERE**
export ACTION_MAILER_PASSWORD=**YOUR DATA HERE**
Notifications are defined in app/services/hyrax/workflow
. There are three kinds of notifications.
-
MiraWorkflowNotification -- These are subclasses of the Hyrax workflow notifications. They are triggered by Sipity workflow events, as defined in
config/workflows/mira_publication_workflow.json
. These include comment notifications, and publishing and unpublishing of single works. -
MiraNotification -- These are single-item notifications which are not triggered by a SipityWorkflow event. These are primarily used for notification of single-item deposits, either via the
/contribute
form or theCreate New Work
form on the admin dashboard. -
MiraBatchNotification -- These are batch notifications. They inherit some behavior from the
MiraNotification
class, but operate at a batch level instead of at an individual level. Examples include batch xml import, batch metadata update, batch publish, batch unpublish, and batch template application.
The /contribute
forms deposit works into specific collections. In order to ensure that the expected collections exist, they are
created at application deploy time and (if necessary) at deposit time via the Tufts::ContributeCollections
class. To change the names or
identifiers of these Collection objects, edit the app/lib/tufts/contribute_collections.rb
file. To create the collections explicitly, run rake tufts:create_contribute_collections
.