Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Configuring Projects and Default Rights
Creating or updating a Project
Creating a new data Project has to be done by an admin of the metamodel Project (oasis.meta). Updating it as well, unless the Project Resource's rights have been setup differently using the Rights API.
First, it's advised to have a dedicated Portal organization (named ex. Ozwillo Datacore poi Admins) that will give admin rights over this Project's Resources. If there's none yet, create one in the Portal and invite there app developers and app admins. Then retrieve its Kernel id (eg by enabling your browser's debug mode and looking in the POST response at creation time or in the GET response at page load time) :
Then, to create a data Project using the Playground (ex. myproject_0), the easiest way is to copy an existing one whose governance policy (configuration & default rights) is the closest to the wished one (see examples in next part) using the Datacore Playground:
- select the Project to be copied in the top project dropdown. The Projet Portal is then displayed in the Playground.
- click on the Project Resource link (first link, ex. poi_0) to get it
- click on the "edit" button of the Playground
- click in the Playground URL bar and remove the project name (in order to prepare a POST but also to allow "undo" later), so that it reads
- select the oasis.meta Project in the top project dropdown, so it'll be the current one (required to update it)
- click in the Playground URL bar and type CTRL-Z, so the URL reverts to
- update the data in the Project Resource :
- remove the o:version line (required for creating a new project)
- remove the dc:creator, dc:created and dc:modified lines
- replace all occurrences of the name (versioned ex. poi_0, unversioned ex. poi) and major version (ex. 0) of the project by the new ones (ex. resp. myproject_0, myproject, 0)
- update the list of visible projects if needed
- do other changes as wished. For that, see next part: visible projects, rights including notably replacing resourceOwners (usually by the id of said Portal organization dedicated to this project's admins) ; and usually: check that dcmp:frozenModelNames and dcmp:allowedModelPrefixes (and dcmp:forkedUris) are empty and that dcmp:modelLevelSecurityEnabled is true (else Resource-level permissions are disabled !) and dcmp:useModelSecurity is false (unless you want different default security among a project's models).
- click on POST to create it.
And it's then advised to:
- if the newly created project is a newer version of an existing project, add its URI in the dcmp:localVisibleProjects property of the "façade" project
- you can do so by GETing eg
/dc/type/dcmp:Project_0/geoin the oasis.meta project, adding the new URI then doing a PUT to save the modifications
- you can do so by GETing eg
- add its URI and name to the oasis.main project's visible projects (dcmp:localVisibleProjects and dcmp:visibleProjectNames), then save the oasis.sandbox so that it's own visible projects are recomputed (both using the Playground's edit/POST button)
- you can do so by GETing
/dc/type/dcmp:Project_0/oasis.sandbox) in the oasis.meta project, editing its properties and doing a PUT to save the modifications
- you can do so by GETing
- notify its resourceOwners of its creation by email.
To update a data Project using the Playground, it's the same, only that obviously that's the Project to be updated that has to be selected and that the name has not to be replaced, and more importantly in the Project Resource the current o:version line must not be removed.
Here's what matters in a Project Resource / Project configuration (see also in the Playground Explore available models and projects):
- its name, which must be unique since it plays the role of an ID. It should be in lower, camel case in the form unversionName_majorVersion (ex. geo_1), unless it is a version-less "façade" project that is only a passthrough link to the latest official major version of a given project (ex. geo, with geo_1 as single visible project).
- its visible Projects (dcmp:localVisibleProjects) : put there (URIs of) all Projects containing data (& models) that is directly referred to from this Project but not in it. NB. don't mind the dcmp:visibleProjectNames field because it is computed.
- dcmp:forkedUris : put there URIs of visible models that you want to fork in this project (i.e. have your own editable copy of it, such as to draft evolutions of it), by then doing GET, edit and POST on each of them.
- generic governance policies : dcmp:frozenModelNames (a list of frozen model names or "*"), dcmp:allowedModelPrefixes.
- its default rights policy, mainly :
- dcmp:modelLevelSecurityEnabled : keep it to true in order to enable Resource-level permissions in addition to default ones, which are the Project's dcmp:securityDefaults or if any its Model's dcmo:security, which last case is only useful if different rights policies have to be set up on each Model of the same Project,
- dcmp:useModelSecurity : keep it to false, unless you want different default security policies on a project's models, in which case you have to define all security fields of this project's models
- and dcmp:securityDefaults (see examples below), whose dcmp:resourceOwners are the project's admins. There also are dcmp:securityConstraints, dcmp:visibleSecurityConstraints (should not be modified unless for facade projects).
Examples of common default (Rights) setups
In short, data permissions are
- default permissions (which are the Project's dcmp:securityDefaults, unless dcmp:useModelSecurity is set to true then (if any) its Model's dcmo:security, which last case is only useful if different rights policies have to be set up on each Model of the same Project),
- plus if dcmp:modelLevelSecurityEnabled, Resource-level permissions (visible in the "ownedEntities" field of the output of queries in debug mode, i.e. using the "?" button in the Playground).
Here are some examples of Project's dcmp:securityDefaults configuration to start from. They can also be applied at a single's Model own dcmo:security.
Import-only public data project
Mainly, it's readable by all (dcms:isAuthentifiedReadable is true) but not writable by anybody (dcms:isAauthentifiedCreatable/Writable is false) except project admins i.e. default resourceOwners. It can also have dcmp:modelLevelSecurityEnabled (and dcmp:useModelSecurity) set to false, unless their ownership is expected to be given to users at some point.
NB. import-only private data would not make sense.
Example : geo_1 (and its façade project geo).
Standard, app (user)-gathered public data Project
It differs in that it's dcms:isAuthentifiedCreatable so that anybody can contribute its own data Resources (and dcms:isAuthentifiedReadable).
Example : poi_0.
Private data Project
It differs from the public data project in that it's not readable by anybody (dcmp:isAuthentifiedReadable is false) (except the owner(s) and project admins).
Example : citizenkin_0 (though it's not required, it also has dcmp:useModelSecurity set to true because all its models have historically defined their own security).