gcube-cms-suite/geoportal-service/docs/ucd.rst

102 lines
3.8 KiB
ReStructuredText
Raw Normal View History

2022-07-06 18:38:26 +02:00
.. _ucd:
2023-01-20 18:24:40 +01:00
##########################
2022-07-06 18:38:26 +02:00
Use Case Descriptors (UCD)
2023-01-20 18:24:40 +01:00
##########################
2022-07-06 18:38:26 +02:00
2023-01-20 18:24:40 +01:00
Use Case Descriptors (**UCD**) are documents used by the application in order to manage the entire lifecycle of registered Projects, including its consumption by users.
UCDs define :
* :ref: Schema : The structure of the related Projects' metadata documents (may depend by PHASE)
* :ref: Data Access Policies : Access rules (i.e. read/write all/own) on which base clients are allowed to operate on Projects
* :ref: Relationship Definitions : Relationships appliable to related Projects
* :ref: Handlers configuration : All expected configurations by handlers involved in the Projects lifecycle (both server-side plugins and clients / GUIs)
*********
Schema
*********
The schema defines the expected structure of the document section of a Project.
It is defined as a map of Fields objects like the following example ::
"_schema":{
"CD" : {"_min":1, "_label" : "IDENTIFICAZIONE","_children" :{
"TSK" : {"_min":1,"_type": "DIRECT-CL", "_values": ["MOSI"],"_label":"Tipo modulo"},
"CMD" : {"_min":1,"_label":"Codice modulo"},
"ESC" : {"_min":1,"_label":"Ente schedatore"},
"ECP" : {"_min":1,"_label":"Ente competente per tutela"},
"CBC" : {"_label":"Identificativo scheda bene culturale"},
"ACC" : {"_max":-1,"_label":"ALTRO CODICE", "_children": {
"ACCE" : {"_label": "Ente/soggetto responsabile","_type": "DIRECT-CL", "_values": ["MATTM","Regione","Ente Territoriale","GNA"]},
"ACCC" : {"_label": "Codice Identificativo","_type": "DIRECT-CL", "_values": ["MATTM","Regione","Ente Territoriale","GNA"]},
"ACCS" : {"_label" : "Note"}}}}}
}
********************
Data Access Policies
********************
This section of a UCD defines how users can access / write Projects based on their role in the current context.
These policies are defined as an array of conditions to apply to a certain set of roles.
.. note:: If "_roles" is empyt, the rule is considered the default policy.
Each policy can also define an **enforcer** policy to apply to each operation that the caller tries to perform.
In the following example ::
"_dataAccessPolicies": [
{"_policy": {"_read": "none","_write": "none"}, "_roles": []
},
{"_policy": {"_read": "any", "_write": "none"},"_roles": ["Guest"],
"_enforcer": {
"_filter": "{\"_lifecycleInformation._phase\" : {\"$eq\" : \"Published\"}}"
}},
{"_policy": {"_read": "any","_write": "none"}, "_roles": ["Admin"]},
{"_policy": {"_read": "any","_write": "any"},"_roles": ["Data-Manager"]}
]
* *Admin* can access any Project
* *Data-Manager* can access and write any Project
* *Guest* can access any project **with phase = Published**
* The default policy is to deny access or writes
************************
Relationship Definitions
************************
Relationships are links between Projects. The UCD contains definitions of the links that can be applied to projects like in the following example::
"_relationshipDefinitions" : [
{"_id": "precedes", "_label" : "Precede","_reverseRelationId" : "follows"},
{"_id": "follows", "_label" : "Segue","_reverseRelationId" : "precedes"}
]
.. note:: Relationships can be applied to Projects related to different UCDs.
***********************
Handlers Configurations
***********************
Hendlers configuration vary a lot in structure in order to allow for the most flwxibility and decoupling of components.
Each entry is expected to be defined as the following ::
{
"_id": ...,
"_type": ...,
"_configuration": {
..
}
}
In this way the declaration can be read from other components (e.g. lifecycle managers when looking for indexers) but the configuration is custom managed by the target handler itself.
See :ref:`plugins` for more informations.