Practically, this is intended as a preparation for #159 / #160 , laying some of the groundwork for managing data.
Projects are intended as a way to organise collections and annotations, and to manage who is allowed to view or update the data. They are represented in both the RDF and SQL database; the SQL representation includes some extra information about who can access the project.
Implemented in this PR:
Admins can create and edit projects through the admin menu.
Projects also have a representation in RDF; Django signals are used to enact changes in the triplestore after the model is updated.
Projects come with a corresponding graph in the triplestore, which can be used to store collections, annotations, etc.
In the SQL database, projects can have groups and users added to them, who will gain read and write access. Projects also have a boolean field public: a public project gives all visitors read access.
There is a view to list all projects that the user had read access to, but it's not used by the frontend.
Note: projects are meant to eventually replace the ResearchGroup model, but that migration is non-trivial, so I will add it in a later update.
This implements a
Projectmodel in the backend, based on the EDPOP collection ontology.Practically, this is intended as a preparation for #159 / #160 , laying some of the groundwork for managing data.
Projects are intended as a way to organise collections and annotations, and to manage who is allowed to view or update the data. They are represented in both the RDF and SQL database; the SQL representation includes some extra information about who can access the project.
Implemented in this PR:
public: a public project gives all visitors read access.Note: projects are meant to eventually replace the
ResearchGroupmodel, but that migration is non-trivial, so I will add it in a later update.