Hyrax v1.0 ( branch: 1.0-stable )
Documentation for Versions:
- I’m on the form to create a new work and I click the
- The data is submitted to the controller for the correct work type. This controller was generated when you did
bin/rails generate hyrax:work <type>. For example the
app/controllers/hyrax/generic_works_controller.rbif you generated a work type of
- This generated controller includes Hyrax::WorksControllerBehavior which includes Hyrax::CurationConcernController, which defines the create method that is run when saving.
createmethod initializes the actor and calls create on it.
- The actor is a stack built of functions that take parts of the form data and act upon them. The actor is customizable in your local application with the default steps of the pipeline defined by Hyrax::ActorFactory’s stack_actors method.
- When create is called, each frame of this stack is called, and expects to have access to curation_concern, attributes, and user which contains the new work, the data from the HTML form, and the current user, respectively.
- One of the frames in the stack is the model_actor. It calls the generated actor specific for the work type we’re making. In this case
app/actors/hyrax/actors/generic_work_actor.rb. This generated actor extends Hyrax::Actors::BaseActor, which is responsible for persisting the object by calling the
- Another frame in the stack is the Hyrax::Actors::InitializeWorkflowActor. This actor creates a workflow entity proxy for the object. This proxy tracks where the work is in the workflow.
- If this object was deposited to an AdminSet that uses the default workflow, then the object is immediately available to be discovered in the search (given the searching user has appropriate on access controls)
- If this object was deposited to an AdminSet that uses the one-step mediated deposit workflow, then the object is marked as suppressed in solr and it’s not available for discovery. The approvers for the admin set were notified that they must take action to review this work.