Skip to content
This repository has been archived by the owner on Oct 4, 2023. It is now read-only.

Approval and feedback #34

Open
kinlane opened this issue Jun 22, 2017 · 2 comments
Open

Approval and feedback #34

kinlane opened this issue Jun 22, 2017 · 2 comments

Comments

@kinlane
Copy link
Contributor

kinlane commented Jun 22, 2017

Opening up a thread dedicated to the approval, feedback, and auditing flow for the platform, that allows anyone to update a record in the system, but there is an approval flow that can be applied before the change is accepted.

This area would overlap with the meta data conversation which involves the change log and logging - #28

@NeilMcKLogic
Copy link

We already have use cases where this is necessary but I'm wondering if/how this would be integrated into HSDA. When someone submits any change to a record via the API, in some cases the change will need to be held aside temporarily until an authorized human can review and approve it for a lot of very important reasons. Perhaps we need something to indicate the status of any POSTed change requested (e.g. pending, approved, rejected, etc) that could be included both in the initial Response to the Request but also queried later.

@kinlane
Copy link
Contributor Author

kinlane commented Aug 31, 2017

I have an initial draft of how HSDA meta + HSDA management will handle this. The one thing the Human Services community is missing currently is the notion of API service composition, which is a staple of API management in the mainstream space. Where APIs (/paths) + VERBS (GET,POST,PUT, DELETE) (services) can be composed into a variety of tiers that users have access to--who can read, write, rate limiting, etc. I've added a project to help move forward the conversation I"m calling HSDA Management, which borrows from the mainstream.

HSDA Manament will work in conjunction with the HSDA meta which records all API transactions, and HSDA orchestration (webhooks, events) to execute an approval / feedback system. Some examples of this could be a POST of an organization that occurs, and is recorded in meta as transaction, but because user doesn't have access in service composition, it doesn't update. After a webhook, email, or other goes out, the transaction can be approved, declined. This would allow this type of approval to exist at the transaction level for each API call, or for batches of API calls (bulk loading). HSDA meta would allow for auditing, rollbacks, of ALL API activity.

More to come on this, as these system get flushed out.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants