hashgraph / guardian Goto Github PK

You can't easily see in the video, but when I click 'Reject' button, the expected action of rejection doesn't happen (nothing happens)

Expected behavior: the application should be rejected and show the appropriate label (v1.0.0-beta.2)

As a User of the Guardian, I would like to create my own policy workflow execution instance, using Step by Step Guidance. Currently there isn't one available, there fore this needs to be created.

Definition of Done: Step by Step Guidance is published in the Repo in either a README, OR a GitBook.

Consider using https://www.gitbook.com/ or Wiki or something similar to publish documentation

As an installer, when I open a policy that hasn't been approved yet, I get a spinning wheel with no indication of what is happening. The spinning wheel doesn't go away. (v1.0.0-beta.2)

Expected behavior: a message saying "Waiting for approval" needs to be shown. This message needs to be dictated by the policy template.

Requirements

Configure CI/CD for adding the following badges:

• Test
• Build
• Release
• .

This issue depends on the implementation of #4

DOD

• A Technical Decision needs be made around which badges are appropriate.
• The ticket is considered done when the acceptance criteria is fulfilled.

Acceptance Criteria

• Appropriate badges are added and displayed.

Can't submit the sample iRec Application Form for the policy provided in the Demo Files

• I've done the configuration

• Imported the schema for the form

• Created a token

• Imported the policy (associated with the token above)

• Associated Installer 1 with the token

• Published the policy

• Installer 1 can't submit the form (see below)

Turns out it was being submitted but there's no confirmation or change in screen. This happened:

Requirements
As a user of the Guardian, I will need to visually see the new wallet implementation. This is linked to issue #58

Pre-requisite
Wallet source code from Infinite World / SUKU or another vendor.

Definition of Done
Tested UX. Tested API's. Test results.

Acceptance Criteria:
Delivered unit-testing results.

The irec-policy-config.txt has the url of the message-broker set as "targetUrl": "http://message-broker:3003/mrv" which works in docker but not when you stand up each component yourself - it should be changed to "targetUrl": "http://localhost:3003/mrv".

Suggest adding to the GitHub ReadMe to change this url for the non Docker build option.

In this readme: https://github.com/hashgraph/guardian/blob/main/README.md
the word component is spelled "componant" at least 4 times. Use CTRL+F to find instances

As a user of the Guardian reference implementation demo, I want to be able to see the changes made to Issue #41 on the User Interface.

DOD: Design prepared for the Development Team that covers this functionality, i.e. the Mockup itself.

Acceptance Criteria: Designer creates these Screens and Obtains Approval from the Stakeholder (Matt at DOVU).

Whoever is creating the Policy needs to be able to define the lists and their values.
Whoever is Filling out the Form needs to be able to select something on that list.

Requirements

As a Guardian user, I want to be able to use lists within schemas.

DOD

• Schema definition language includes provision for defining lists.
• Unit tests exists for the schema and the API.
• Schema documentation is updated to include description of lists functionality.

Acceptance Criteria

• A user can define lists in schemas and specify whether they are multi-select or not.

Problem description

As a user, I would like for my Policies and Schemas to be discoverable beyond just my own business infrastructure silo. Currently, all schemas are stored in an internal database, therefore, we need to add the option to store schemas in a publicly accessible database or distributed storeage.

Requirements

The action of creation a schema must be recorded in a specific topic in Hedera, associated with the specific Authority. The internal database currently used needs to be synced with an IPFS node[s] for storing all system artefacts in the following way:

• Local Guardian instance includes a DB which contains drafts and 'cached' published policies and schemas
• When a schema or a policy version is published it becomes immutable and is uploaded onto the IPFS via nft.storage API. NFT Storage guarantees the permanence of the uploaded info on IPFS.
• The ID of the published schema/policy is posted into the corresponding Hedera topic.
• This should work with the versioning functionality as per #46

There will be another ticket to do with the 'discoverability' of assets (Policies, Schemas) and the 'import' of these artefacts into a Guardian instance for DR and other reasons.

There is a broader ticket #324 that covers all the work we are going to do to decentralise Guardian, beyond to just publishing schemas/policies on IPFS.

Please note that published data need to be verifiably immutable as per #162.

Definition of Done

• Acceptance criteria is fulfilled
• Documentation is updated

Acceptance Criteria

• Published schemas/policies are accessible via IPFS gateway
• Guardian instance (after the sync) operating performance is not affected

Requirements
As a Developer user of the Guardian, I would like Postman API Documentation to Guide me

Pre-requisite
Postman Procurement Acquisition?

Definition of Done
Postman API Output. Output Format (.MD?)

Acceptance Criteria:
Output Documentation for Postman API?

N/A:
@anvabr and at myself really, Just a reminder from Wes: Please add Nicola to the “community notice” in addition to DOVU for DoD

ACCEPTANCE CRITERIA: Update the README with how to get started with Swagger.

@danielnorkin To deploy GitHub Issue Template as soon Hedera adds Daniel to the project as a "Maintainer" with adequate permissions.

LABELLING AS A QUESTION AND HELP WANTED. NOT ASSIGNING STORY POINTS (AS SPRINT IS IN PROGRESS!)

Problem description

Non-offset GHG reductions, such as those resulting from corporate energy conservation or efficiency initiatives, are currently not supported in Guardian. These are generally measured as the delta between the baseline and current emission levels, there are no concepts/tools which would allow Guardian users to account for these, and link/reflect them on the Environmental scorecards ( #1017).

Requirements

Introduce the ability to mint Mitigation Asset Type tokens as the result of the calculation of the diff between planned (and reported on the Environmental) and actual results of the calculations based on the MRV data for a reporting period.

Definition of done

• Detailed research on how to perform Mitigation Credits in guardian
• Creating a Powerpoint Presentation to explain the process
• Creating a workflow diagram, demonstrating the implementation of the process.

Acceptance criteria

Research on how a company is able to automatically account for mitigation efforts through MRV data processing by the policy engine resulting in the production of mitigation tokens.

As a user (Root Authority) of the Guardian, I would like to describe the policy in the memo field of a topic on the Hedera Hashgraph network. This will allow public audibility of details pertaining to the policy being created.

Note - There is a current restriction to the size of the memo field (100 bytes). We will need to figure out a workaround in the event a description will be larger than 100 bytes.

ACCEPTANCE CRITERIA: Removed Policy ID from the Policy Creation Table, and Add a Hedera Topic ID Column with a clickable link.

When you set the decimal places to 2 on the token configuration the guardian UI shows 100 tokens being minted but Hedera shows 1. Need to update to ensure the 2 values align.

Requirements
As a user of the Guardian, I may want to create custom roles / actors that are outside of the roles / actors built within the reference implementation. That functionality doesn't exist, therefore an enhancement to the Policy Engine is needed.

Pre-requisite
IA Diagram? BRD? FSD?

Definition of Done
IA Diagram? BRD? FSD?

Acceptance Criteria:
IA Diagram? BRD? FSD?

This page points to the Usage Demo Guide. Screenshot below:

The link is broken.

Requirements
As a user of the reference implementation version of the Guardian, prior to publishing a Policy Workflow Execution Instance, I would like to see the validated requirements such as schemas, tokens, etc. If there is an issue, I will want to see the issue and see how to fix it. This is related to issue #56.

Pre-requisite
BRD. IA Diagram?

Definition of Done
BRD. IA Diagram?

Acceptance Criteria:
BRD. IA Digram?

ui-service npm install failing at [email protected].

To Reproduce
Steps to reproduce the behavior:
run "npm install" in the ui-service folder. Install fails.
OR run "npm install did-sdk-js@git+https://github.com/EnvisionBlockchain/did-sdk-js.git" and it also fails.

Expected behavior
To install.

Log
0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli '/Users/gavinerasmus/.nvm/versions/node/v14.18.1/bin/node',
1 verbose cli '/Users/gavinerasmus/.nvm/versions/node/v14.18.1/bin/npm',
1 verbose cli 'install',
1 verbose cli 'did-sdk-js@git+https://github.com/EnvisionBlockchain/did-sdk-js.git'
1 verbose cli ]
2 info using [email protected]
3 info using [email protected]
4 verbose npm-session ac12a5ea8f3bed07
5 silly install loadCurrentTree
6 silly install readLocalPackageData
7 verbose prepareGitDep undefined: installing devDeps and running prepare script.
8 error prepareGitDep 1>
8 error prepareGitDep > [email protected] postinstall /Users/gavinerasmus/.npm/_cacache/tmp/git-clone-49a723a2/node_modules/protobufjs
8 error prepareGitDep > node scripts/postinstall
8 error prepareGitDep
8 error prepareGitDep
8 error prepareGitDep > [email protected] postinstall /Users/gavinerasmus/.npm/_cacache/tmp/git-clone-49a723a2/node_modules/nodemon
8 error prepareGitDep > node bin/postinstall || exit 0
8 error prepareGitDep
8 error prepareGitDep
8 error prepareGitDep > [email protected] prepare /Users/gavinerasmus/.npm/_cacache/tmp/git-clone-49a723a2
8 error prepareGitDep > npm run build
8 error prepareGitDep
8 error prepareGitDep
8 error prepareGitDep > [email protected] build /Users/gavinerasmus/.npm/_cacache/tmp/git-clone-49a723a2
8 error prepareGitDep > tsc
8 error prepareGitDep
8 error prepareGitDep ../../../../node_modules/@types/express-serve-static-core/index.d.ts(505,18): error TS2430: Interface 'Response' incorrectly extends interface 'ServerResponse'.
8 error prepareGitDep Property 'req' is optional in type 'Response' but required in type 'ServerResponse'.
9 error prepareGitDep 2> npm WARN install Usage of the --dev option is deprecated. Use --also=dev instead.
9 error prepareGitDep npm WARN prepublish-on-install As of npm@5, prepublish scripts are deprecated.
9 error prepareGitDep npm WARN prepublish-on-install Use prepare for build steps and prepublishOnly for upload-only.
9 error prepareGitDep npm WARN prepublish-on-install See the deprecation note in npm help scripts for more information.
9 error prepareGitDep npm ERR! code ELIFECYCLE
9 error prepareGitDep npm ERR! errno 2
9 error prepareGitDep npm ERR! [email protected] build: tsc
9 error prepareGitDep npm ERR! Exit status 2
9 error prepareGitDep npm ERR!
9 error prepareGitDep npm ERR! Failed at the [email protected] build script.
9 error prepareGitDep npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
9 error prepareGitDep
9 error prepareGitDep npm ERR! A complete log of this run can be found in:
9 error prepareGitDep npm ERR! /Users/gavinerasmus/.npm/_logs/2021-10-20T07_22_08_510Z-debug.log
9 error prepareGitDep npm ERR! code ELIFECYCLE
9 error prepareGitDep npm ERR! errno 2
9 error prepareGitDep npm ERR! [email protected] prepare: npm run build
9 error prepareGitDep npm ERR! Exit status 2
9 error prepareGitDep npm ERR!
9 error prepareGitDep npm ERR! Failed at the [email protected] prepare script.
9 error prepareGitDep npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
9 error prepareGitDep
9 error prepareGitDep npm ERR! A complete log of this run can be found in:
9 error prepareGitDep npm ERR! /Users/gavinerasmus/.npm/_logs/2021-10-20T07_22_08_585Z-debug.log
10 silly fetchPackageMetaData error for did-sdk-js@git+https://github.com/EnvisionBlockchain/did-sdk-js.git premature close
11 timing stage:rollbackFailedOptional Completed in 1ms
12 timing stage:runTopLevelLifecycles Completed in 11436ms
13 verbose stack Error: premature close
13 verbose stack at PassThrough.onclose (/Users/gavinerasmus/.nvm/versions/node/v14.18.1/lib/node_modules/npm/node_modules/end-of-stream/index.js:47:67)
13 verbose stack at PassThrough.emit (events.js:412:35)
13 verbose stack at emitCloseNT (internal/streams/destroy.js:87:10)
13 verbose stack at processTicksAndRejections (internal/process/task_queues.js:81:21)
14 verbose cwd /Users/gavinerasmus/Development/projects/hedera/guardian/ui-service
15 verbose Darwin 20.6.0
16 verbose argv "/Users/gavinerasmus/.nvm/versions/node/v14.18.1/bin/node" "/Users/gavinerasmus/.nvm/versions/node/v14.18.1/bin/npm" "install" "did-sdk-js@git+https://github.com/EnvisionBlockchain/did-sdk-js.git"
17 verbose node v14.18.1
18 verbose npm v6.14.15
19 error premature close
20 verbose exit [ 1, true ]

Desktop (please complete the following information):

• OS: BigSur 11.6 (IOS).
• VS Code
• NodeJS v14.18.1

While editing a policy, there's an action to restart the service:

The functionality wasn't clear to me at first. My understanding is that it's supposed to restart the guardian-ui-service running on docker.

Two observations:

• If that's the intended functionality, then it's not working as intended. It only terminates the ui-service but does not restart it
• The purpose of having the functionality there is not clear (not sure if it's documented somewhere)

Describe the bug
guardian-service start with error: PrecheckStatusError: transaction ... failed precheck with status TRANSACTION_EXPIRED

To Reproduce
Steps to reproduce the behavior:

1. Clone main (cbbfd3b)
2. Update OPERATOR_ID and OPERATOR_KEY in .env, .env.docker and config.json
3. docker-compose up -d --build
4. docker-compose logs -f guardian-service
5. See following error

guardian-service_1  |
guardian-service_1  | > [email protected] start
guardian-service_1  | > node dist/index.js
guardian-service_1  |
guardian-service_1  | /usr/vc-modules/node_modules/@hashgraph/sdk/lib/PrecheckStatusError.cjs:23
guardian-service_1  |     super(props, `transaction ${props.transactionId.toString()} failed precheck with status ${props.status.toString()}`);
guardian-service_1  |     ^
guardian-service_1  |
guardian-service_1  | PrecheckStatusError: transaction [email protected] failed precheck with status TRANSACTION_EXPIRED
guardian-service_1  |     at new PrecheckStatusError (/usr/vc-modules/node_modules/@hashgraph/sdk/lib/PrecheckStatusError.cjs:23:5)
guardian-service_1  |     at TopicCreateTransaction._mapStatusError (/usr/vc-modules/node_modules/@hashgraph/sdk/lib/transaction/Transaction.cjs:944:12)
guardian-service_1  |     at TopicCreateTransaction.execute (/usr/vc-modules/node_modules/@hashgraph/sdk/lib/Executable.cjs:391:22)
guardian-service_1  |     at processTicksAndRejections (node:internal/process/task_queues:96:5) {
guardian-service_1  |   status: Status { _code: 4 },
guardian-service_1  |   transactionId: TransactionId {
guardian-service_1  |     accountId: AccountId {
guardian-service_1  |       shard: Long { low: 0, high: 0, unsigned: false },
guardian-service_1  |       realm: Long { low: 0, high: 0, unsigned: false },
guardian-service_1  |       num: Long { low: 3013031, high: 0, unsigned: false },
guardian-service_1  |       _checksum: null
guardian-service_1  |     },
guardian-service_1  |     validStart: Timestamp {
guardian-service_1  |       seconds: Long { low: 1636335862, high: 0, unsigned: false },
guardian-service_1  |       nanos: Long { low: 927085674, high: 0, unsigned: false }
guardian-service_1  |     },
guardian-service_1  |     scheduled: false
guardian-service_1  |   }
guardian-service_1  | }

Expected behavior
guardian-service should start without error.

Desktop (please complete the following information):

• OS: MacOS 11.6
• Docker version 20.10.8, build 3967b7d

Additional context
It was working last week. No change to the guardian code.

As a user of the Guardian, I would like to make sure that all messages are processed. This means that if the Guardian were to go offline for any reason, any missed messages will be processed when it goes back online. This functionality does not exist, so it is a new enhancement.

Trying to load this VP: http://localhost:3002/trust-chain?search=8bcc81d2-b5b8-48d5-aef9-75b80bb95119

When I type it into the field or click from the MRVs page on its ID, I get the following error:

ERROR TypeError: s is undefined
    loadData http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    __tryOrUnsub http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    notifyNext http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    r http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    invokeTask http://localhost:3002/polyfills-es2017.5c9e07b76195d53e7d9c.js:1
    onInvokeTask http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    invokeTask http://localhost:3002/polyfills-es2017.5c9e07b76195d53e7d9c.js:1
    runTask http://localhost:3002/polyfills-es2017.5c9e07b76195d53e7d9c.js:1
    invokeTask http://localhost:3002/polyfills-es2017.5c9e07b76195d53e7d9c.js:1
    p http://localhost:3002/polyfills-es2017.5c9e07b76195d53e7d9c.js:1
    f http://localhost:3002/polyfills-es2017.5c9e07b76195d53e7d9c.js:1
    P http://localhost:3002/polyfills-es2017.5c9e07b76195d53e7d9c.js:1
    scheduleTask http://localhost:3002/polyfills-es2017.5c9e07b76195d53e7d9c.js:1
    onScheduleTask http://localhost:3002/polyfills-es2017.5c9e07b76195d53e7d9c.js:1
    scheduleTask http://localhost:3002/polyfills-es2017.5c9e07b76195d53e7d9c.js:1
    scheduleTask http://localhost:3002/polyfills-es2017.5c9e07b76195d53e7d9c.js:1
    scheduleEventTask http://localhost:3002/polyfills-es2017.5c9e07b76195d53e7d9c.js:1
    A http://localhost:3002/polyfills-es2017.5c9e07b76195d53e7d9c.js:1
    handle http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _trySubscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    subscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    call http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    subscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    V http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _innerSub http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _tryNext http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    M http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _trySubscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    subscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    call http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    subscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    call http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    subscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    call http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    subscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    loadData http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    ngOnInit http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    __tryOrUnsub http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    UP http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    activateRoutes http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    activateChildRoutes http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    activateChildRoutes http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    activate http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    setupNavigations http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    notifyNext http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    M http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _trySubscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    subscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    call http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    subscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    V http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _innerSub http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    notifyNext http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    M http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _trySubscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    subscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    V http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _innerSub http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    notifyNext http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    M http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _trySubscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    subscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    V http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _innerSub http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _tryNext http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    notifyNext http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    M http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _trySubscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    subscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    call http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    subscribe http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    V http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _innerSub http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    notifyNext http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    _next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1
    next http://localhost:3002/main-es2017.a0f5204a99ebcef930e6.js:1

Step 6 of the Demo Usage Guide in README.md doesn't currently mention that the mint_token workflow step needs to be connected to the token created in the previous step.

It needs to be added

Problem Description

As a user of the Guardian, there may be a situation where a policy will require complex calculation rules of measurement, reporting, and validation (MRV) data. Currently, there is are Policy Workflow Actions like mint and aggregate. This issue is related specifically to enhancing the aggregate Policy Workflow Action.

Requirements

Introduce facilities into the Policy Engine (PE) - in the definition language, and PE functionality - to perform the following:

• track the history of MRV measurements for the current 'observation period', e.g. remember that it received 20 MRVs in the last hour.
• ability for the policy creator to specify and the for PE validate that MRVs arrive correctly, e.g. every 30 minutes. Highlight in the auditor view when/where there were problems.
• policy can specify what to do if the requirement for MRV reporting from the sensor is not fulfilled for the period of time specified in the minting section (e.g. skip minting a token).
• ability to use external information (e.g. current date/time in the most simple case) and conditionally execute action (e.g. mint a token)
• capability to aggregate/calculate based on a temporal/calendar dimension (e.g. 'observation period'):
  • establish the beginning of the period (date/time/calendar significant milestone such as the beginning of the month etc)
  • set a duration of the period or periodicity rule (such as monthly, weekly, etc)
  • count the occurrences of an event during each period
  • perform other arithmetic calculation, e.g translate the number of event occurrences into CO2 a volume in tons. I believe we already have math capability in there, for the MVP we would need to have hard-coded formulas/constants. For the future the constants will become variables sourced from an Oracle or other external system.
  • do an action (mint token) on the basis of the above
• capability to aggregate/calculate based on a cumulative dimension
  • count the occurrences of an event until it reaches a defined volume measure
  • perform other arithmetic calculation, such as translate the number of event occurrences into CO2 a volume in tons
  • do an action (mint token) on the basis of the above

Please see google calendar event settings for the repeat events for inspiration.

Furthermore, Policy language needs to be extended to support the functionality of mandating an MRV reporting period (from the sensor) such that:

• Policy can specify a temporal requirement for the receiving of the signal from the sensor (e.g. "every 15 minutes").
• Policy can specify what to do if the requirement above is not fulfilled for the period of time specified in the minting section (e.g. skip minting a token).

DOD

• Requirements and acceptance criteria fulfilled.
• Documentation updated to include description of these capabilities.
• Mock-up sensor is enhanced to provide use-cases for the demo
• Demo script updated to include a use-case for the above

Acceptance Criteria

• Stakeholder review passed
• Requirements fulfilled

Problem description

Guardian is required to operate at the 'enterprise-level', potentially handling large numbers of users, documents and transactions. At present there are no quantitative data about its ability to fulfil this requirement, and therefore no strategy or best practices can be developed for scaling the solution for different use-cases.

Requirements

• Create an automated scalability and capacity testing framework using, ideally, OSS tools.
• Run and establish capacity baseline.
• Integrate these into our release pipeline so the changes can be monitored for every release.
• Experiment and extend the test suite to identify bottlenecks and develop understanding of the system capacity behaviour in various deployment (scale) configurations.

Definition of done

• Automatic test load scripts exists, using API.
• Test can be triggered with minimal manual involvement.
• The test framework is extendable.

Acceptance criteria

• Coverage for capacity and scalability testing end-to-end for iREC and VERRA demo policies.
• Token mints tests are included.

Notes

Benchmark: - Need a timebound of 3,000 TPS Across these categories for 24 hours and then 7 days as the benchmarks. If it goes down, need to reconnect. Hedera has one client on the CTE side is looking to do this number of transactions, so this is where this requirement is driven from.

Requirements
As a user (Root Authority) of the Guardian, I would like to be able to simply import a single file (i.e .zip) that contains everything needed to create my Policy Workflow Execution Instance. The file would contain information related to:

• Roles
• Schemas
• Policy Workflow
• Etc

Similarly, I would like to perform an export that would download everything contained within a Policy Workflow Execution Instance such as:

• Roles
• Schemas
• Policy Workflow
• Etc

Definition Of Done:

• The Acceptance Criteria is fulfilled
• A test ZIP file is present in the repository
• A test which can be run by anyone on where that file gets imported into the system.
• Documentation updated with the description of this functionality.

Acceptance Criteria

• There is an input/export path where the system accepts the package (ZIP file) containing multiple artefacts.
• Upon the 'import' action these artefacts are propagated into the right 'places' in the system and appear in the UI as if they were created there.
• Upon the 'export' action the list of artefacts associated with the particular policy is packaged into a ZIP file and downloaded automatically onto the client's computer. This package can then be imported as per the point above.

Requirements
As a user of the Guardian, prior to publishing a Policy Workflow Execution Instance, I would like to validate requirements such as schemas, tokens, etc. If there is an issue, I will need to know what requirement the issue is related to and how to fix it.

Pre-requisite
Reference Ticket? BLOCKER Ticket?

Definition of Done
Reference Ticket? BLOCKER Ticket?

Acceptance Criteria:
Reference Ticket? BLOCKER Ticket?

Requirements:
As a Guardian user, I should be notified if the data entered is not in the appropriate format as defined in the schema.

Definition of Done:

• The implementation passed the acceptance criteria.
• There is a test schema in the codebase which contains all supported types with which 'Forms Validation' functionality can be tested.
• There is a document which describes the currently supported types and their possible values.

Acceptance Criteria:

• Validation of the form data should match that of schema type definition, i.e. the same values that would be rejected by the schema type definition as invalid should be rejected by the form validation logic, and vice versa the same values that are considered valid by the schema type definition should pass form validation.
• When a user inputed a malformed value into a field, a clear and user-friendly message for the user showing which input field contains invalid value and why.

Requirements
As a user of the Guardian reference implementation demo, I want to be able to see the changes made to Issue #43 on the User Interface.

Pre-requisite
Remediation of Blocker Tickets. Mendel to Address.

Definition of Done
TBD

Acceptance Criteria:
TBD

Requirements
As a user of the Guardian, I Securely, would like to use a wallet to store my private and public keys. Currently, the reference implementation is storing keys in Mongo, so this feature needs to be added.

Pre-requisite
Choice of Wallet

Definition of Done
Successful Key Management Unit Testing Outputs

Acceptance Criteria:
Successfully passing Key Management Unit Tests.

Describe the bug
When using the installation documentation finishing with docker-compose up -d --build the message-queue module was hitting an AbortSignal issue whereby there was a clash with particular interface definitions.

To Reproduce
Steps to reproduce the behavior:

1. Follow the installations instructions for building with docker

Expected behavior
Docker completes installation and runs all services.

Desktop (please complete the following information):

• MacOS 10.15.7
• Node v16.7.0 (Using NVM)
• Docker version 20.10.5

Additional context
Will provide a PR to resolve the issue.

Expected Solution
Update tsconfig.json (message-broker) with skipLibCheck to bypass ts interface checks that have clashes. Once there is production-ready stability for the guardian there should be a view to remove this flag.

Requirements
See step 2 in: https://github.com/hashgraph/guardian#installation. Step 2 instructions are not valid, therefore confusing/unnecessary.

Pre-requisite
I added my testnet credentials to the files, once the app is built and run the credentials have to be entered again or generated randomly.

Definition of Done
IT SECURITY and Credential Entry Pass Unit - Test?

Acceptance Criteria:
IT SECURITY and Credential Entry Pass Unit - Test?

N/A:
On that same note, when adding the credentials, if I add the public key instead of the private key of the account I get useful errors for the Installer accounts (something along the lines of "Invalid key length"). The error message for the RootAuthority is not helpful

https://github.com/hashgraph/guardian/blob/main/README.md#demo-usage-guide

The first sentence of this section reads:
"Place holder for some Executive Summary about the iRec Demo"

^ Should delete that and go into steps

The name next to the person icon is currently not clickable, only the person icon.

Expected behavior: Clicking on the name of the account should show the same menu as clicking on the persona icon.

Problem definition

As a user of the Guardian, I would like a retirement process for ESG assets (see #290 for matched). This is the other end of the token lifecycle, opposite to the 'creation' process, which also needs its own ruleset.

Assets may include:

• Carbon Emission Tokens (CET)
• Carbon Removal Units (CRU)
• Core Carbon Principals (CCP)

Requirements

• Expand Policy definition language to have provisions to specify rules for retirement (not only for creation as it is now) of sustainability tokens
• Implement smart contract functionality enforcing these rules.

DOD

• Acceptance criteria fulfilled
• Documentation updated accordingly

Acceptance criteria

• Policy creators are able to specify rules for the retirement of assets, including for 'matched' assets as per #290
• Hedera enforces these rules for all created tokens with or without the instance of the Guardian present through a retirement smart contract associated with each policy.
• Guardian has an API to retire tokens

Requirements
As a user of the Guardian, I would like to see the changes on the frontend that are related to issue #51.

Pre-requisite
Front End UX?

Definition of Done
Front End UX QA Demo

Acceptance Criteria:
Unsure?? @anvabr ?

Problem description

As a user of the Guardian, there could a situation when Policy and one of its schemas are already used, but I need to edit the change them to reflect the change in the regulations.

Requirements

1. Policies and Schemas are assigned versions when they are published.
2. Policies and Schemas versions and published date are displayed in the UI whenever a user can see or otherwise access the the corresponding document.
3. The system preserves all previous published versions of policies and schema documents, i.e previously published version is stored in the DB and can be retrieved from the UI.
4. For the moment publishing a new version of the schema has no effect on existing configurations of policies and users (installers, auditors etc continue working under the policy version they've been working on). This is potenatilly to change in the future (will be specified in a separate ticket).

DOD

• Acceptance criteria fulfilled
• Demo policies are updated to include versions

Acceptance criteria

• Valid policies and schema documents must contains version information, otherwise they are considered invalid and not processed
• Document version is visible in the UI wherever the name of the corresponding document is displayed
• All published version of the documents can be accessed by users

Requirements
As a user of the Guardian, prior to publishing a Policy Workflow Execution Instance, I would like to validate requirements such as schemas, tokens, etc. If there is an issue, I will need to know what requirement the issue is related to and how to fix it.

Pre-requisite
Information Architecture Diagrams? BRD's? FSD's for this Enhancement / Feature?

Definition of Done
The CI should cover linting as well as unit tests at a minimum.

Acceptance Criteria:
The CI should cover linting as well as unit tests at a minimum.

@danielnorkin To deploy GitHub Issue Template as soon Hedera adds Daniel to the project as a "Maintainer" with adequate permissions.

LABELLING AS A QUESTION AND HELP WANTED. NOT ASSIGNING STORY POINTS (AS SPRINT IS IN PROGRESS!)

As a user of the Guardian, I would like to be able to edit schemas as they are created. This functionality does not currently exist, therefore we need to be added.