Send Accept when creating a ticket
When a project receives an Offer{Ticket} in which the project is the Offer’s target, the project creates a new ticket, and inbox-forwards that Offer to the project team and followers (at the time of writing, it means for a project /s/joe/p/myproj, only /s/joe gets notified, I haven’t properly implemented the team and followers stuff yet ^_^).
However, no Accept activity it sent. And if the Offer is rejected for any reason, no Reject activity is sent.
As long as tickets are automatically accepted, it’s not critical that Vervis doesn’t use Accept and Reject, but, before I deploy the federated open-new-ticket demo, I want to have Accept and Reject properly implemented. In 3 steps:
- Implement handling of these activities in the inbox, and implement authoring of them by project actors
- Send Accept when automatically accepting ticket
- Send Reject when the recipient project is the Offer’s target but for some reason automatically rejects the offer (for example some mismatch etc. in the activity’s fields)
What would the Accept look like? Relevant properties:
- “object”: What is being accepted?
- “target”: Into which place is it being accepted?
Do we need “target” here? It would be the sender project itself, so, not much use in it. Let’s start without it, and add it later if there’s real need.
So, the Accept would just have an “object”. URI, or an embedded JSON object? Before we answer that, we need to ask: What do we accept? The ticket or the offer? Both sound reasonable. Since the Offer contains the Ticket, I prefer to use the Offer. Also, the AP spec uses Accept{Follow} and implies Accept{Offer}, so let’s prefer to accept the activity rather than an object inside it.
Embedded object or just URI?
When an actor is notified on the Accept, and they wish to see the actual ticket, which is very likely, how do they find it? That may be what matters the most here. One way is to fetch the Offer activity (if it’s still online!) and grab the Ticket from inside it. Another way is to fetch the hosted ticket (likely to be online because we just received an Accept from that server).
It seems the “result” property would be good here, it can point from the Accept to the created Ticket.
DECISION: Start with Accept having the following:
- “object”: URI of the Offer
- “result”: URI of the new Ticket
Switch these URIs into full objects (with “id” though) if the need arises.
Status: Open