@@ -25,9 +24,10 @@ Discussions with various Module Owners and CSP is in progress and below requirem
...
@@ -25,9 +24,10 @@ Discussions with various Module Owners and CSP is in progress and below requirem
• Development or modification of any API or backend code<br/><br/>
• Development or modification of any API or backend code<br/><br/>
<h2>2. Detailed Business Requirements - Functional</h2>
<h2>2. Detailed Business Requirements - Functional</h2>
Below are the point of contacts driving the requirements for Admin UI Project:
Below are the point of contacts driving the requirements for Admin UI Project:
<table><thead><th>Modules</th><th>Point of Contact</th><th>Initial Business Requirements Discussion</th><th>User Stories Received</th><th>API Availability</th><th>Prototype Screens Developed</th><th>Access to API</th><thead><tbody><tr><td>Information Security</td><td>Paco Hope</td><td>Completed</td><td>Completed</td><td>Yes</td><td>In Progress</td><td>No</td></tr><tr><td>Data Platform</td><td>Philip Jong & Stephen Whitley</td><td>Completed</td><td>In Progress</td><td>To be Identified</td><td>To be Created</td><td>No</td></tr><tr><td>Data Ingestion</td><td>Stephen Whitely</td><td>Completed</td><td>To be Identified</td><td>To be Identified</td><td>To be Created</td><td>No</td></tr><tr><td>E&O</td><td>Hrvoje Markovic</td><td>Completed</td><td>In Progress</td><td>Yes</td><td>Yes</td><td>No</td></tr><tr><td>Audit and Metrics</td><td>Nidhi Fotedar</td><td>Open</td><td>To be Identified</td><td>To be Identified</td><td>To be Created</td><td>No</td></tr><tr><td>Data Loading</td><td>Michael Haven</td><td>Completed</td><td>To be Identified</td><td>To be Identified</td><td>To be Created</td><td>No</td></tr><tr><td>System Configuration</td><td>Raj Kannan</td><td>In Progress</td><td>To be Identified</td><td>To be Identified</td><td>To be Created</td><td>No</td></tr></tbody></table>
<table><thead><th>Modules</th><th>Point of Contact</th><th>Initial Business Requirements Discussion</th><th>User Stories Received</th><th>API Availability</th><th>Prototype Screens Developed</th><th>Access to API</th><thead><tbody><tr><td>Information Security</td><td>Paco Hope</td><td>Completed</td><td>Completed</td><td>Yes</td><td>In Progress</td><td>No</td></tr><tr><td>Data Platform</td><td>Philip Jong & Stephen Whitley</td><td>Completed</td><td>In Progress</td><td>To be Identified</td><td>To be Created</td><td>No</td></tr><tr><td>Data Ingestion</td><td>Stephen Whitely</td><td>Completed</td><td>To be Identified</td><td>To be Identified</td><td>To be Created</td><td>No</td></tr><tr><td>E&O</td><td>Hrvoje Markovic</td><td>Completed</td><td>In Progress</td><td>Yes</td><td>Yes</td><td>No</td></tr><tr><td>Audit and Metrics</td><td>Nidhi Fotedar</td><td>Open</td><td>To be Identified</td><td>To be Identified</td><td>To be Created</td><td>No</td></tr><tr><td>Data Loading</td><td>Michael Haven</td><td>In Progress</td><td>To be Identified</td><td>To be Identified</td><td>To be Created</td><td>No</td></tr><tr><td>System Configuration</td><td>Raj Kannan</td><td>In Progress</td><td>To be Identified</td><td>To be Identified</td><td>To be Created</td><td>No</td></tr></tbody></table>
<h4>a. Login Screen</h4>
<h4>a. Login Screen</h4>
<ul><li>Initially Philip had provided requirements for a login and register screens. However, after discussions with Paco and Philip individually, it was decided that login screens should not be created for Admin UI</li><li>Authentication and authorization will happen using the IDP and E&O APIs</li><li>Access to OSDU Admin UI tool will be through bearer token generated through the IDP where the OSDU data platform is deployed</li><li>Admin UI Portal will have unique URL’s depending on which instance it has been hosted on. </li><li>Login and Registration is not part of Admin UI Development. It will be taken care by Organisations in their own IDP.</li></ul>
<ul><li>Initially Philip had provided requirements for a login and register screens. However, after discussions with Paco and Philip individually, it was decided that login screens should not be created for Admin UI</li><li>Authentication and authorization will happen using the IDP and E&O APIs</li><li>Access to OSDU Admin UI tool will be through bearer token generated through the IDP where the OSDU data platform is deployed</li><li>Admin UI Portal will have unique URL’s depending on which instance it has been hosted on. </li><li>Login and Registration is not part of Admin UI Development. It will be taken care by Organisations in their own IDP.</li><li><b>Question asked by Johan - Where do you refer to Roles based access? Since it needs to be Roles based + then only selective access to approved features.</b><br/>
-- As per our discussion with Hrvoje on Entitilements & Obligation module, the role based access will be taken care in E & O user group section and each individual API will take care of the user validation internally. </li></ul>
<h4>b. Landing page (Home page)</h4>
<h4>b. Landing page (Home page)</h4>
After Successful authentication from the respective IDP, user will be redirected to the Landing page (Home page).<br/>This home page will list below modules:<br/>
After Successful authentication from the respective IDP, user will be redirected to the Landing page (Home page).<br/>This home page will list below modules:<br/>
o Entitlement and Obligation <br/>
o Entitlement and Obligation <br/>
...
@@ -40,19 +40,33 @@ Discussions with various Module Owners and CSP is in progress and below requirem
...
@@ -40,19 +40,33 @@ Discussions with various Module Owners and CSP is in progress and below requirem
<h4>c. Entitlement and obligation (E&O) Module</h4>
<h4>c. Entitlement and obligation (E&O) Module</h4>
Entitlements service is used to enable authorization in Data Ecosystem. The service allows for the creation and user mapping for groups. A group name defines a permission. Users who are added to that group obtain that permission. The main motivation for entitlements service is data authorization but the functionality enables three use cases:<br/>
Entitlements service is used to enable authorization in Data Ecosystem. The service allows for the creation and user mapping for groups. A group name defines a permission. Users who are added to that group obtain that permission. The main motivation for entitlements service is data authorization but the functionality enables three use cases:<br/>
<ol><li>Data groups used for data authorization e.g. data.welldb.viewer, data.welldb.owner</li><li>Service groups used for service authorization e.g. service.storage.user, service.storage.admin </li><li>User groups used for hierarchical grouping of user and service identities e.g. users.datalake.viewers, users.datalake.</li></ol>
<ol><li>Data groups used for data authorization e.g. data.welldb.viewer, data.welldb.owner</li><li>Service groups used for service authorization e.g. service.storage.user, service.storage.admin </li><li>User groups used for hierarchical grouping of user and service identities e.g. users.datalake.viewers, users.datalake.</li></ol>
<p>For each group a user can either be added as an OWNER or a MEMBER. The only difference being if you are an OWNER of a group, then you can manage the members of that group.</p>
<p>For each group a user can either have an OWNER role or a MEMBER role. The only difference being an OWNER of a group is that you can manage the members of respective group.</p>
<p>In Entitlement and obligation page users will have 2 sections Manage Users and Manage Groups. Depending on the visitor’s access level few functionalities like deletion, creation and editing will be enables or disabled. The groups and user mapping will be done via Entitlements Module where the group owner will have access to edit the group permissions for the users. </p>
<p>In Entitlement and obligation page users will have 2 sections Manage Users and Manage Groups. Depending on the visitor’s access level few functionalities like deletion, creation and editing will be enables or disabled. The groups and user mapping will be done via Entitlements Module where the group owner will have access to edit the group permissions for the users. Only the owner of the group can create a user or give permission to use it. </p>
<p>Under E & O Manage Users section we are managing role and permission for a particular member.</p>
<table> <thead> <tr> <th></th> <th></th> <th colspan="4">Dev Rest End Point (URL/Not Available)</th> </tr> <tr> <th>API Name</th> <th>API Purpose</th> <th>AWS</th> <TH>Azure</TH> <th>Google</th> <th>IBM</th> </tr> </thead> <tbody> <tr> <td>GET /entitlements/v1/groups</td> <td>Gives list of the groups that user belongs to</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> </tr> <tr> <td>POST /entitlements/v1/groups</td> <td>Creates the group within the data partition with following email {name}@{data-partition-id}.{domain}.com</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> </tr> <tr> <td>GET /entitlements/v1/groups/{group_email}/members</td> <td>Retrieves members that belong to a group.</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> </tr> <tr> <td>POST /entitlements/v1/groups/{group_email}/members</td> <td>Add members to a group.</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> </tr> <tr> <td>POST /entitlements/v1/groups/data/{group_email}/members</td> <td>Add user group of a primary partition to a data group of a vendor partition.</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> </tr> <tr> <td>DELETE /entitlements/v1/groups/{group_email}/members</td> <td>Delete members from a group within the data partition provided.</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> </tr> </tbody> </table>
<h4>d. Data Ingestion</h4>
<h4>d. Data Ingestion</h4>
Yet to receive inputs.
Yet to receive inputs. <br/>
<p> Data Ingestion and Data Loading is a process of getting data into the system. </p>
<table><thead><tr><th></th><th></th><thcolspan="4">Dev Rest End Point (URL/Not Available)</th></tr><tr><th>API Name</th><th>API Purpose</th><th>AWS</th><TH>Azure</TH><th>Google</th><th>IBM</th></tr></thead><tbody><tr><td>Not Available</td><td>Not Available</td><td>Not Available</td><td>Not Available</td><td>Not Available</td><td>Not Available</td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>
<h4>e. Data Loading</h4>
<h4>e. Data Loading</h4>
No user stories received during initial discussions. Follow up calls planned.
No user stories received during initial discussions. Follow up calls planned. <br/>
<p>As per our discussion with Michael, in data loading access is limited and user account should be able to locate master data, prod data, etc based on their type and permission.</p>
<p>There are three types of users: </p>
<ol>
<li>User who can do everything.</li><li>User who can only upload prototype.</li><li>User who can only upload master data.</li></ol>
<p>But owner can manage all data.</p>
<table><thead><tr><th></th><th></th><thcolspan="4">Dev Rest End Point (URL/Not Available)</th></tr><tr><th>API Name</th><th>API Purpose</th><th>AWS</th><TH>Azure</TH><th>Google</th><th>IBM</th></tr></thead><tbody><tr><td>Not Available</td><td>Not Available</td><td>Not Available</td><td>Not Available</td><td>Not Available</td><td>Not Available</td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>
<h4>f. Data Platform</h4>
<h4>f. Data Platform</h4>
User stories discussions are in progress. Discussed on requirements to include legal tags update, follow up calls planned.
User stories discussions are in progress. Discussed on requirements to include legal tags update, follow up calls planned.
<table><thead><tr><th></th><th></th><thcolspan="4">Dev Rest End Point (URL/Not Available)</th></tr><tr><th>API Name</th><th>API Purpose</th><th>AWS</th><TH>Azure</TH><th>Google</th><th>IBM</th></tr></thead><tbody><tr><td>Get All Well</td><td>To get list of all wells and it’s details which user has access to</td><td>https://389u8yyazd.execute-api.us-east-1.amazonaws.com/api/search/v2/query/</td><td>Not Available</td><td>Not Available</td><td>Not Available</td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>
<h4>g. Information Security</h4>
<h4>g. Information Security</h4>
Below are some of the user stories captured as part of login and initial admin tasks:
Below are some of the user stories captured as part of login and initial admin tasks:
<ul><li>System Administrator</li><li><ul><li>User should be able to login as a system administrator Check for the roles will be done by E&O roles/groups API</li><li>User should be able to configure the OSDU user authentication system to use my company’s IDP. As part of initial setup, an IDP will be configured for authentication of Admin App</li><li>User should be able to set up the authentication system for Single Sign On for users – This will be during initial setup itself</li><li>User should be able to be able to assign roles of the OSDU users – E&O APIs will be called for these operations</li></ul></li><li>System Administrator (roles assignments, system configurations)</li><li><ul><li>System Operator (system monitoring, reporting, dashboarding, etc) – To be discussed and reviewed with what all APIs are available</li><li>Data Manager (Data Loading, ingestion, E&O policy management) To be discussed and reviewed with what all APIs are available</li></ul></li><li>Users (login)</li><li><ul><li>User should be able to configure access to the external data sources (EDS) As part of initial setup, an IDP will be configured for authentication of Admin App</li><li>User should be able to configure the system behaviours (e.g., the visibility of metadata if the actual data is protected) As long as the APIs are available to update the system behaviours, this should be possible</li></ul></li><li>System Operator (Comments as above)</li><li><ul><li>User should be able to login as a system operator</li><li>User should be able to able to run all system audit and operation reporting services</li><li>User should be able to configure the system dashboard</li><li>User should be able to run the system reporting services and create the dashboard</li></ul></li><li>Data Manager (Comments as above)</li><li><ul><li>User should be able to load and ingest data with manifests</li><li>User should be able to load and ingest data without manifests</li><li>User should be able to load and ingest master data</li><li>User should be able to load and ingest reference data</li><li>User should be able to load and ingest quality rules</li><li>User should be able to see a list of all currently-running ingestion jobs with their current status</li><li>User should be able to see a history of recent (for some definition of recent) ingestion jobs, with their status (and maybe size, number of objects, error log, etc.)</li><li>User should be able to kill/cancel a currently-running ingestion job</li></ul></li><li>End Users (Comments as above)</li><li><ul><li>User should be able to login as an end user</li><li>User should be able to be able to search for availability of data</li><li>User should be able to access the application and service catalog of the Marketing Site</li><li>User should be able to be able to purchase the application or service</li><li>Once I purchase the application or service, they will appear on the application of service pages</li><li>User should be able to execute an application or service which I purchase</li><li>User should be able to list all purchased data sets</li></ul></li></ul>
<ul><li>System Administrator</li><li><ul><li>User should be able to login as a system administrator Check for the roles will be done by E&O roles/groups API</li><li>User should be able to configure the OSDU user authentication system to use my company’s IDP. As part of initial setup, an IDP will be configured for authentication of Admin App</li><li>User should be able to set up the authentication system for Single Sign On for users – This will be during initial setup itself</li><li>User should be able to assign roles of the OSDU users – E&O APIs will be called for these operations</li></ul></li><li>System Administrator (roles assignments, system configurations)</li><li><ul><li>System Operator (system monitoring, reporting, dashboarding, etc) – To be discussed and reviewed with what all APIs are available</li><li>Data Manager (Data Loading, ingestion, E&O policy management) To be discussed and reviewed with what all APIs are available</li></ul></li><li>Users (login)</li><li><ul><li>User should be able to configure access to the external data sources (EDS) As part of initial setup, an IDP will be configured for authentication of Admin App</li><li>User should be able to configure the system behaviours (e.g., the visibility of metadata if the actual data is protected) As long as the APIs are available to update the system behaviours, this should be possible</li></ul></li><li>System Operator (Comments as above)</li><li><ul><li>User should be able to login as a system operator</li><li>User should be able to able to run all system audit and operation reporting services</li><li>User should be able to configure the system dashboard</li><li>User should be able to run the system reporting services and create the dashboard</li></ul></li><li>Data Manager (Comments as above)</li><li><ul><li>User should be able to load and ingest data with manifests</li><li>User should be able to load and ingest data without manifests</li><li>User should be able to load and ingest master data</li><li>User should be able to load and ingest reference data</li><li>User should be able to load and ingest quality rules</li><li>User should be able to see a list of all currently-running ingestion jobs with their current status</li><li>User should be able to see a history of recent (for some definition of recent) ingestion jobs, with their status (and maybe size, number of objects, error log, etc.)</li><li>User should be able to kill/cancel a currently-running ingestion job</li></ul></li><li>End Users (Comments as above)</li><li><ul><li>User should be able to login as an end user</li><li>User should be able to search for availability of data</li><li>User should be able to access the application and service catalog of the Marketing Site</li><li>User should be able to purchase the application or service</li><li>Once I purchase the application or service, they will appear on the application of service pages</li><li>User should be able to execute an application or service which I purchase</li><li>User should be able to list all purchased data sets</li></ul></li></ul>
<h4>h. Audit and Metrics (system monitoring)</h4>
<h4>h. Audit and Metrics (system monitoring)</h4>
To be updated
To be updated <br/>
<p>All the traceability and individual diagnostics regarding the CRUD activity happening in Data Platform will be available in this module. </p>
<table><thead><tr><th></th><th></th><thcolspan="4">Dev Rest End Point (URL/Not Available)</th></tr><tr><th>API Name</th><th>API Purpose</th><th>AWS</th><TH>Azure</TH><th>Google</th><th>IBM</th></tr></thead><tbody><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>
<h2>3. Design & Development Approach</h2>
<h2>3. Design & Development Approach</h2>
Below is the high-level understanding based on various discussions with stakeholders till now.<br/>
Below is the high-level understanding based on various discussions with stakeholders till now.<br/>
1. As part of the Admin UI project, only the front end (GUI) will be developed. All APIS will be provided along with details of authentication & Authorization servers to access these APIs using right authentication (bearer) tokens. There would not be any login or register screen that will be developed as part of Admin UI Project.<br/>
1. As part of the Admin UI project, only the front end (GUI) will be developed. All APIS will be provided along with details of authentication & Authorization servers to access these APIs using right authentication (bearer) tokens. There would not be any login or register screen that will be developed as part of Admin UI Project.<br/>
...
@@ -67,12 +81,12 @@ Discussions with various Module Owners and CSP is in progress and below requirem
...
@@ -67,12 +81,12 @@ Discussions with various Module Owners and CSP is in progress and below requirem
<br/>
<br/>
4. During the initial setup of OSDU instance, a super user is added to various groups. This superuser will be responsible for configuring the groups access to various other users using Admin UI Application. The entitlements API’s will be used to manage users and groups mapping <br/>
4. During the initial setup of OSDU instance, a super user is added to various groups. This superuser will be responsible for configuring the groups access to various other users using Admin UI Application. The entitlements API’s will be used to manage users and groups mapping <br/>
5. Below is a prototype screen of how the initial landing page will look like: <br/><br/>
5. Below is a prototype screen of how the initial landing page will look like: <br/><br/>
Below is a prototype screen of how the E&O manage users/groups page will look like: <br/><br/>
Below is a prototype screen of how the E&O manage users/groups page will look like: <br/><br/>
<ul><li>User with Owner role will be able to add a member and delete a member from his group</li><li>Owner can also decide the permission of member that is going to be added in that group</li><li>All the logged in users irrespective of their role will be able to view the members of their group</li><li>Search functionality is also provided to users to ease their work</li></ul>
<ul><li>User with Owner role will be able to add a member and delete a member from his group</li><li>Owner can also decide the permission of member that is going to be added in that group</li><li>All the logged in users irrespective of their role will be able to view the members of their group</li><li>Search functionality is also provided to users to ease their work</li></ul>
<b>6. Manage Groups </b><br/>
<b>7. Manage Groups </b><br/>
Below is a prototype screen of how the E&O manage groups page will look like:<br/><br/>
Below is a prototype screen of how the E&O manage groups page will look like:<br/><br/>
<ul><li>User with Owner role and Admin or Creator permission will be able to create a group and can also delete a group</li><li>User with Owner role and Viewer permission can only view the list of groups and member inside a group</li><li>Search functionality is also provided to users to easily search a group or user</li></ul>
<ul><li>User with Owner role and Admin or Creator permission will be able to create a group and can also delete a group</li><li>User with Owner role and Viewer permission can only view the list of groups and member inside a group</li><li>Search functionality is also provided to users to easily search a group or user</li></ul>
...
@@ -81,7 +95,7 @@ Discussions with various Module Owners and CSP is in progress and below requirem
...
@@ -81,7 +95,7 @@ Discussions with various Module Owners and CSP is in progress and below requirem
<p>This section defines the assumptions made for the user acceptance process</p>
<p>This section defines the assumptions made for the user acceptance process</p>
<ol><li>The project assumes only UI (frontend development). All API’s are to be provided by the individual module owners</li><li>Instance specific IDP will be used for authentication and all APIs are expected to validate the roles and access before returning the results</li><li>This project will not update or create any new API’s or any backend code</li><li>End deliverable for this project is going to be Angular 9 code which can be deployed to any CSPs</li></ol>
<ol><li>The project assumes only UI (frontend development). All API’s are to be provided by the individual module owners</li><li>Instance specific IDP will be used for authentication and all APIs are expected to validate the roles and access before returning the results</li><li>This project will not update or create any new API’s or any backend code</li><li>End deliverable for this project is going to be Angular 9 code which can be deployed to any CSPs</li><li><b>Question asked by Johan - Audit trail needs to be available for all key entries.</b> (Need to discuss further on this.)</li></ol>
<h2>6. Glossary</h2>
<h2>6. Glossary</h2>
<p>The glossary provides definitions of all the key business terms used in this document.</p>
<p>The glossary provides definitions of all the key business terms used in this document.</p>
@@ -89,7 +103,9 @@ Discussions with various Module Owners and CSP is in progress and below requirem
...
@@ -89,7 +103,9 @@ Discussions with various Module Owners and CSP is in progress and below requirem
<p>Below are key risks and issues specific to the Admin UI Project:</p>
<p>Below are key risks and issues specific to the Admin UI Project:</p>
a. Unavailability of pre-flight environment – A development environment is yet to be provided to the development team (23 Nov 2020)<br/>
a. Unavailability of pre-flight environment – A development environment is yet to be provided to the development team (23 Nov 2020)<br/>
b. As per discussions till now, there are several APIs required for Admin UI project which are either in development or not yet developed now. This unavailability of APIs may delay Admin UI development significantly
b. As per discussions till now, there are several APIs required for Admin UI project which are either in development or not yet developed now. This unavailability of APIs may delay Admin UI development significantly
<h2>8. Appendix</h2>
<h2>8. Asks and Open Items</h2>
<table> <thead> <th>Questions</th> <th>Point of Contact</th> <th>Status</th> </thead> <tbody> <tr> <td>As per the discussion so far there are 7 different modules to be developed. Need to confirm with OSDU team if these are the final no of modules.</td> <td>Stephen Whitley</td> <td>Open</td> </tr> <tr> <td rowspan="4">Need Read and Write access to preflight environment and endpoint for all 4 cloud platforms</td> <td>GCP - Ferris(fargyle@google.com) </td> <td>Open</td> </tr> <tr> <td>IBM - Wlad(wsfrazao@us.ibm.com)-IBM</td> <td>Open</td> </tr> <tr> <td>AWS - Paco(pacohope@amazon.com)</td> <td>Open</td> </tr> <tr> <td>Azure – Hrvoje (HMarkovic@slb.com)</td> <td>Open</td> </tr> <tr> <td>In Entitlement API’s is the data pattern going to be different for different IDP’s?</td> <td>Hrvoje</td> <td>Open</td> </tr> <tr> <td>In Admin UI home page do we have to show all the modules irrespective of user’s role and permission, or do we get API which will provide us the list of modules that the user has access to?</td> <td></td> <td>Open</td> </tr> <tr> <td>What will be the data partition id for different API’s ?</td> <td></td> <td>Open</td> </tr> <tr> <td>Request for a bootcamp session for various cloud providers like Google, Azure and IBM.</td> <td></td> <td>Open</td> </tr> </tbody> </table>
<h2>9. Appendix</h2>
<p>Below are the resources shared by various module owners as part of initial discussion:</p>
<p>Below are the resources shared by various module owners as part of initial discussion:</p>
<ul><li>Gitlab Directory for Admin UI Project - https://community.opengroup.org/osdu/ui/admin-ui</li><li>API Postman Collection - https://community.opengroup.org/osdu/platform/testing/-/tree/master/Postman%20Collection</li><li>Module Links from teams meeting</li> https://community.opengroup.org/osdu/platform<br/>
<ul><li>Gitlab Directory for Admin UI Project - https://community.opengroup.org/osdu/ui/admin-ui</li><li>API Postman Collection - https://community.opengroup.org/osdu/platform/testing/-/tree/master/Postman%20Collection</li><li>Module Links from teams meeting</li> https://community.opengroup.org/osdu/platform<br/>
