New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Approval and feedback #34

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

Comments

Projects
None yet
2 participants
@kinlane
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

@kinlane kinlane added the road map label Jun 22, 2017

@NeilMcKechnie

This comment has been minimized.

Show comment
Hide comment
@NeilMcKechnie

NeilMcKechnie Aug 10, 2017

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.

NeilMcKechnie commented Aug 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kinlane

kinlane Aug 31, 2017

Contributor

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.

Contributor

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 join this conversation on GitHub. Already have an account? Sign in to comment