Background
Objects in several projects
A project is an undertaking: the holdings, an exhibition, a loan request, a campaign. It is the frame you work in, and every view, every filter and every export refers to it.
An object is a record: a painting, a piece of furniture, a bundle of documents. Objects do not belong to a project. They are linked to projects, to as many as you like.
Why it is built this way
The alternative would be copies. A painting that is in the holdings, was shown in a special exhibition and has just been requested as a loan would be recorded three times. Three condition reports on three records. A correction to the dimensions would have to be repeated in three places, and at some point that stops happening.
In Moliri it is one object with three links. The dimensions are there once, the image is there once, and there is one history. The registrar who handles the loans and the conservator who records the condition work on the same record.
What is shared and what is not
Everything on the object is shared: field values, files, annotations on fields, the history, and events too, unless the link is restricted to one project.
What is project-specific is the view of it:
| What | Behaviour |
|---|---|
| Which layouts exist | Set per project, through the layout’s assignment |
| Which fields are visible | Made up of permissions, project and layout; can differ from project to project |
| Wahl and trash | Per project. An object can be active in project A and in the trash in B |
| Pinning and hiding | Per user and project |
| Filters, sorting, view fields | Per user and project |
| Link to an event | Global, unless it is restricted with This project only |
Project-specific values
Sometimes a value applies only in one project. An object’s catalogue number is its number in this exhibition. The loan status belongs to the loan request, not to the holdings.
For this, a field can carry a value of its own in each project. The value without a project is the shared base value and appears in all projects that have none of their own. A field with a project-specific value shows one value in the exhibition and another in the holdings.
As soon as the object is linked to more than one project, a scope bar appears above the object view. There you choose whether an entry changes the base value or the value for this project. The table of what ends up where and when is under Project-specific values .
The configuration of a field can also differ per project, such as a shorter selection list in the exhibition. That is a separate mechanism and a matter for the setup, see Field configuration .
What surprises people
Deleting removes from the project, not from the database. Delete object in the object menu moves the object to the trash in this project (the confirmation reads Move object to the trash?). In other projects it stays as it was, and Restore object brings it back. If you want to take an object out of a project entirely, remove the link under Assign projects. Even then the values remain and are back when you link the object again. The last link cannot be removed: An object must stay linked to at least one project. See Delete an object .
A change takes effect everywhere. If you correct the dimensions, you correct them in all projects the object is in. That is intended, but it surprises you if you do not expect it. Where shared data is changed, the interface points this out, for a shared event with Changes affect all n linked objects, for example.
The history records the project. A change is attributed to the project in which it was made. The project history therefore shows not only changes in this project but also changes to the base values of its objects.
Creating objects across project boundaries
Because links are free, there are creation rules. A project can specify that new objects are created in another project, typically the holdings, and are only linked here. Further projects can be linked in addition. Conversely, an exhibition can be set up so that loans are created only there and do not appear in the institution’s own holdings.
When creating an object, Moliri reports where it went, for example Created in »Holdings« and linked here. Chains are not followed: if the target project itself creates objects somewhere else, that does not apply to this operation. Because such a rule writes objects into another project, the target project sees it under Incoming rules. The rules are set up on the Object creation tab, see Create a project .
Further reading
- Project-specific values : scope bar, storage scope and what ends up where
- Link an object to projects : individually and in bulk
- History : how changes are assigned to projects