New Issue Products Endpoint

[marfavi]

Motivation

The storage crew in Analog gets product rewards for doing extra work in the cafe. This is a way to provide an incentive while not giving elevated perks (such as always-free espresso). For example, checking the storage for missing milk rewards one free fancy drink, and ordering milk is good for 10 fancy drinks.

By creating an endpoint to directly add clip cards/"swipable products" to a user, we can automate distrubution of these rewards with Zapier webhook or similar.

Implementation suggestions

Endpoint

POST api/v2/purchases/issue-product 
POST api/v2/vouchers/issue-product

Request body

{
  "IssueToUserId": 1,
  "ProductId": 6,
  "ProductAmount": 10,
  "Reason": "Purchaser reward",
  "Requester": "Zapier on behalf of Storage Manager"
}

Execution

Upon checking that the requester is authorized to issue products, there are multiple ways to issue the products themselves:

• Generate vouchers and immediately "redeem" them for the user. This provides the same logging as the generate vouchers endpoint.
• Add products directly into the user's account, possibly adding a way to log this transaction as a both a free purchase and an instance of a product handout in the process.

Further comments

Should the user be notified that new products have been added to their account? (This would complicate things.)

[TTA777]

Some comments:

• The product amount is specified as part of the product itself, so shouldn't be part of this request.
• With the recent change to purchases, we now support different purchase types in the database so that would likely be preferable than trying to shoe horn this into vouchers
• We could consider utilizing the new PosPurchase table to contain some of the data, i.e., requester.

[jonasanker]

I agree with Thomas that the request should reference a ProductId. Assuming there is a need to issue multiple "purchases" of the same product to a user, I would lean towards that this should currently not be supported. Then the request must be repeated instead.

This case is best handled as a new endpoint on the Purchase API which could potentially handle both PosPurchases and FreePurchases. Every completion of a purchase always ends with a fulfilment, that is issuing tickets to the user. This would be the same for the issue-products endpoint.
We should be mindful about using the PosPurchases table as this currently has a different concept than free purchases. Also for PosPurchases we are required to link with a Pos transaction, like the iZettle OrderId or so. So for PosPurchases we are probably due to update the data model to support this.

Last note. Calling this from Zapier sounds like a security risk which would entail that Zapier stores account information. We might not go in this direction.

[A-Guldborg]

IMO (as the storage manager who would benefit from this), we don't get much improvement by adding an automatic setup to issue products directly to user accounts from the current issue voucher service we have. I would save 5-10 minutes per week assuming the setup works without issues, whereas it would also mean that the baristas who are awarded products might not be as aware of their rewards as they currently are (with redeeming vouchers).

I don't think this should be prioritized much (at all?) after we have gotten the issue vouchers service.