-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
gh-308 - Rename DataRequest to DataSpecification
- Loading branch information
Showing
131 changed files
with
2,648 additions
and
2,385 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -35,19 +35,20 @@ Although not essential, it would be beneficial to apply this profile to the data | |
2. Providing additional information for help in choosing appropriate data elements to request for a user's own purposes. | ||
3. Auto-populating the search filters to provide advanced search capabilities. | ||
|
||
# User Requests | ||
# User Data Specifications | ||
|
||
The primary use case of the Mauro Data Explorer is to: | ||
|
||
1. Browse or search the provided catalogue for data elements. | ||
2. Gather data elements of interest to the user into a formal _user request_. | ||
3. Submit this user request to the organisation running this instance to gain access to the real data sets owned by the organisation, based on the data elements requested. | ||
2. Gather data elements of interest to the user into a formal _user data specification_. | ||
3. Submit this user data specification to the organisation running this instance to gain access to the real data sets owned by the organisation, | ||
based on the data elements specified. | ||
|
||
The current implementation considers user requests to be _data models_ in their own right - they are created under the access level of the user signed-in to the Mauro Data Explorer, then populated with data elements before they are submitted. The sections below go into further detail. | ||
The current implementation considers user data specifications to be _data models_ in their own right - they are created under the access level of the user signed-in to the Mauro Data Explorer, then populated with data elements before they are submitted. The sections below go into further detail. | ||
|
||
## Requests Folder | ||
## Data Specifications Folder | ||
|
||
Every user who signs in to the Mauro Data Explorer will automatically be assigned a folder within the Mauro instance to collect their own requests in one place. This folder is located in Mauro where the `explorer.config.root_request_folder` is defined, which is a [configuration key](SETUP.md#configuration-keys) provided by the `mdm-plugin-explorer`. A root request folder is automatically created by the `mdm-plugin-explorer` called "Explorer Content", though the API property can be changed to any other folder if required. | ||
Every user who signs in to the Mauro Data Explorer will automatically be assigned a folder within the Mauro instance to collect their own data specifications in one place. This folder is located in Mauro where the `explorer.config.root_data_specification_folder` is defined, which is a [configuration key](SETUP.md#configuration-keys) provided by the `mdm-plugin-explorer`. A root data specification folder is automatically created by the `mdm-plugin-explorer` called "Explorer Content", though the API property can be changed to any other folder if required. | ||
|
||
The user's folder is named after the user's email address for uniqueness. | ||
|
||
|
@@ -57,30 +58,30 @@ The user's folder is named after the user's email address for uniqueness. | |
> | ||
> For a user signed-in with the email address `[email protected]` | ||
> | ||
> The user request folder will be located under `explorer.config.root_request_folder` and named `user[at]test.com`. | ||
> The user's data specification folder will be located under `explorer.config.root_data_specification_folder` and named `user[at]test.com`. | ||
This request folder is created along with a new user group containing that user. This group is then assigned to the [editor role](https://maurodatamapper.github.io/user-guides/permissions/permissions/#editor) to allow that user (normally with a read-only role) to create catalogue items underneath it. | ||
This data specification folder is created along with a new user group containing that user. This group is then assigned to the [editor role](https://maurodatamapper.github.io/user-guides/permissions/permissions/#editor) to allow that user (normally with a read-only role) to create catalogue items underneath it. | ||
|
||
Once created, the Mauro instance will contain a set of sub-folders similar to below, assuming the default root request folder is used: | ||
Once created, the Mauro instance will contain a set of sub-folders similar to below, assuming the default root data specification folder is used: | ||
|
||
* Explorer Content | ||
* user1[at]test.com | ||
* user2[at]test.com | ||
* etc | ||
|
||
## Creating Requests | ||
## Creating Data Specifications | ||
|
||
Each user will automatically create user request data models, usually via another action to also assign data elements to them. The data models created will: | ||
Each user will automatically create user data specification data models, usually via another action to also assign data elements to them. The data models created will: | ||
|
||
1. Be created directly under their own requests folder. | ||
1. Be created directly under their own data specification folder. | ||
2. Be accessible only to that user or administrators. | ||
3. Be created as a draft. In the context of the Mauro Data Explorer, these are "unsent" requests which may still be edited. | ||
3. Be created as a draft. In the context of the Mauro Data Explorer, these are "unsent" data specifications which may still be edited. | ||
|
||
A user is able to create more than one unsent request at once. | ||
A user is able to create more than one unsent data specification at once. | ||
|
||
## Copying Data Elements | ||
|
||
The signed-in user will be able to copy data elements from the root data model into their own request model. This uses the following Mauro endpoint to accomplish this: | ||
The signed-in user will be able to copy data elements from the root data model into their own data specification model. This uses the following Mauro endpoint to accomplish this: | ||
|
||
``` | ||
PUT api/dataModels/{sourceDataModelId}/subset/{targetDataModelId} | ||
|
@@ -102,20 +103,20 @@ The `subset` endpoint is a core Mauro endpoint which allows a deep copy of a set | |
3. Any related data types from the source data model, if they do not already exist. | ||
4. All requested data elements, stored under the child data class copy. | ||
|
||
## Submitting Requests | ||
## Submitting Data Specifications | ||
|
||
Once happy with the collection of data elements gathered, the user will be able to submit their request to the organisation hosting the Mauro Data Explorer. Submission covers several areas: | ||
Once happy with the collection of data elements gathered, the user will be able to submit their data specification to the organisation hosting the Mauro Data Explorer. Submission covers several areas: | ||
|
||
1. The request data model is [finalised](https://maurodatamapper.github.io/user-guides/finalising-data-models/finalising-data-models/). | ||
1. The data specification data model is [finalised](https://maurodatamapper.github.io/user-guides/finalising-data-models/finalising-data-models/). | ||
2. The current implementation of `mdm-plugin-explorer` will email a notification to an administrator. | ||
|
||
At this point, the Mauro Data Explorer does not handle the submitted request anymore, the request for data access now falls under the control/responsibility of the hosting organisation. | ||
At this point, the Mauro Data Explorer does not handle the submitted data specification anymore, the request for data access now falls under the control/responsibility of the hosting organisation. | ||
|
||
It is possible for a user to create a new version of a previously submitted request, using the same [versioning](https://maurodatamapper.github.io/user-guides/branch-version-fork/branch-version-fork/) mechanisms that all data models have. This will create a new draft version which can be modified again before being submitted (finalised) a second time. | ||
It is possible for a user to create a new version of a previously submitted data specification, using the same [versioning](https://maurodatamapper.github.io/user-guides/branch-version-fork/branch-version-fork/) mechanisms that all data models have. This will create a new draft version which can be modified again before being submitted (finalised) a second time. | ||
|
||
# Template Requests | ||
|
||
Instead of creating User Requests from scratch, it is possible to base a request off of a _template_. This is a pre-made request that is finalised and can be forked to make a copy from. | ||
Instead of creating user data specifications from scratch, it is possible to base a data specification off of a _template_. This is a pre-made data specification that is finalised and can be forked to make a copy from. | ||
|
||
## Templates Folder | ||
|
||
|
@@ -125,4 +126,4 @@ The `mdm-plugin-explorer` will automatically: | |
2. Secure this folder to only be read by the "Explorer Readers" user group. | ||
3. Install the API property `explorer.config.root_-_template_folder` pointing to this folder. | ||
|
||
This will be the root folder to store any finalised template requests. The Mauro Data Explorer `/templates` page route will list all available templates and allow the user to inspect them and copy from them. Copying involves forking the Data Model request to build the copy, which is then automatically moved to the current user's personal request folder. | ||
This will be the root folder to store any finalised template data specifications. The Mauro Data Explorer `/templates` page route will list all available templates and allow the user to inspect them and copy from them. Copying involves forking the template data specification to build the copy, which is then automatically moved to the current user's personal data specification folder. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
File renamed without changes.
Oops, something went wrong.