Need to confirm a workflow

[cmcavoy]

@toolness / @andrewhayward wanted to confirm that the following workflow for CEM could work. If it doesn't work with the current implementation of Aestimia, how much would we need to change? The intent here is to field a CEM site (essentially a CSOL-lite implementation) without having to store any kind of state on the CEM site. We don't have user accounts, so why store any data at all? If the following flow works, then I think we can hit that goal.

1. A user submits evidence and their email for a particular badge.
2. CEM calls Aestimia with a bundle of information, the users email, the evidence, and the badge they're applying for.
3. Aestimia evaluation happens.
4. Aestimia approves or disapproves the application.
5. Aestimia calls CEM and says there's been a state change. Aestimia passes a transaction id only.
6. CEM calls Aestimia back with the transaction id and requests the details. CEM gets the email, evidence and badge id back.
7. CEM processes the application, emailing - openbadgering - whatever.
8. CEM calls Aestimia back and lets them know that transaction id xxxx has been processed, and should be marked as processed.
9. Aestimia marks the transaction received or processed or something.

[andrewhayward]

In general, I think I agree. However, I'm not sure as I understand the same thing by 'transaction id' that you do. Right now, it's possible for the same application to have multiple evaluations, or what I think of as 'transactions'.

In the case of CEM, given that we're trying to avoid any kind of fixed state, we won't have the option for a user to go back and update an application - they'll just have to start again, with a fresh application. However, to generalise the situation, we'll need to know which evaluations have been picked up on, regardless of how many are made for any given application.

So, my understanding of the situation:

1. A user submits evidence and their email for a particular badge.
2. CEM calls Aestimia with [...].
3. Aestimia evaluation happens.
4. Aestimia approves or disapproves the application (a 'transaction').
5. Aestimia calls CEM and says there's been a state change. Aestimia passes an application id only.
6. CEM calls Aestimia back with the application id and requests the details. CEM gets the email, evidence and badge id back, as well as all evaluations (i.e. relevant transactions).
7. CEM processes the most recent evaluation, emailing - openbadgering - whatever.
8. CEM calls Aestimia back and lets them know that the evaluation referenced by transaction id xxxx has been processed, and should be marked processed.
9. Aestimia marks the evaluation ('transaction') received or processed or something.

Off the top of my head, I don't think this means much needs to change.

• Aestimia evaluations need a public ID (UUID, or similar).
• Aestimia evaluations need a seen flag.
• Aestimia needs to pass these attributes with each evaluation blob to CEM when it requests information about an application.
• Aestimia needs an endpoint which CEM can hit to make Aestimia aware that it's processed an evaluation. We might need to work out some form of security (a signing process, perhaps) regarding this.
• Aestimia needs to make visible the seen flag in the UI somewhere.
• Aestimia needs to make it possible for an admin user to re-ping CEM, if it becomes apparent that an evaluation hasn't been picked up on.

[cmcavoy]

yes - agreed - application id is what I'm thinking.

So - next step is clearly ticketing out the things that need to change. Not sure what the gap is between the workflow above and what's current.

[andrewhayward]

Upon further investigation, we need to file tickets to:

• [x] expose the ID in the <review> model (which already exists in the database).
• [x] extend the <review> model to add a seen attribute.
• [x] expose the new seen attribute in the UI.
• [x] extend the achievement block of the <submission> model to handle external IDs (or, potentially, any other meta data).
• [x] add an endpoint to the API to allow clients to notify the system that reviews have been seen. This should be somewhat secure, to prevent unwanted updates. Putting it behind the standard authentication should be sufficient, for example posting {reviewId: <ID>} to /api/submissions/:submissionId.
• [x] allow a user to 're-notify' a client, if it becomes apparent that a review has not been picked up on.

[andrewhayward]

Everything needed for the stateless workflow seems to be in place.