This will allow to use this representation for Offer and Create activities.
When creating a new MR, the inner Offer's 'object' is a 'Patch' object. When
serving an existing hosted MR, the inner Offer's 'object' is just a URI
pointing to the patch.
If sharer receives Accept on an Offer/Dep where the sharer hosts the child
ticket, it records a RemoteTicketDependency and runs inbox forwarding to ticket
followers. But this relies on a TicketDependencyOffer record already existing.
I'll take care of that in the next patches.
sharerAcceptF and sharerRejectF now use the insertToInbox from
Vervis.Federation.Util instead of their own copies of it, which were identical
anyway. Perhaps gradually all the inbox insertion in all S2S handlers will
switch to using that function.
To be honest, this is a huge patch that changes tons of stuff and probably
should have been broken up into small changes. But I already had the codebase
not building, so... just did all of this at once :P
Basically this patch does the following:
- DB migrations for ticket dependency related tables, e.g. allowing a remote
author and a remote child
- Allowing S2S handlers to provide an async continued processing function,
which is executed and the result then added to the debug page
- Most UI and functionality related to ticket deps is disabled, new
implementation being added gradually via ActivityPub
- Improvements to AP tools, e.g. allow to specify multiple hosts for approved
forwarding when sending out an activity, and allow to specify audience of
software-authored activities using a convenient human-friendly structure
- Implementation of S2S sharerOfferDepF which creates a dependency under a
sharer-hosted ticket/patch and sends back an Accept
- Sharer-patch was already working due to the shared DB tabled
- Repo-patch support added
- Fixed a bug in following project-tickets: It allowed to follow a
sharer-ticket by sending the Follow to the project. Now, the project allows
to follow only the project-tickets, and refuses to handle a sharer-ticket.
Also fixed a bug in which trying to follow a ticket with nonexistent
ltkhid/talkhid would result with 404 as if the actor inbox is nonexistent. Now,
there's a friendly message reported.
The examples in the security vocabulary's spec use "Key" but the JSON-LD
context doesn't define that term. From now on, just in case, recognizing both
"Key" and "CryptographicKey" as indication that the object is a key.
zPlus, thanks for finding this bug!
This is the first step preparing for patches and merge requests.
The work-item aspect of MRs will reuse the Ticket related tables, except MRs
will live under repos. So, the context of tickets will no longer be just
projects, but will also be repos.
So, TicketProjectLocal turns into TicketContextLocal, and there are 2 new
tables that refer to it: TicketProjectLocal and TicketRepoLocal. Tickets will
have the former, MRs will have the latter.
Removed its usage in pseudo-client when publishing a comment, and removed it
from inbox forwarding when handling a remote comment.
Very possibly, the ticket team collection will be entirely removed. For now
leaving it there as-is. Just not using it for addressing in activities.
The implementation felt quite weird, had to add an extra field to Fetched and
to VerifKeyDetail. Should probably figure out the whole mess in that code, have
something clean there. Easily add fields. Easily and safely re-fetch an actor
or key.
Now it's much clearer when looking at the code, that these routes are about
project-hosted tickets, and it's easier to see where the author-hosted
equivalents are missing.
IMPORTANT: Since a lot of ticket code still doesn't use TicketUnderProject,
creating tickets now appears to be failing. Usage of this patch as is, is at
your own risk ^_^ the next patches will update the ticket handlers to fix this
problem.
Delivery of an activity into local inboxes is being done using custom local
functions. Each C2S or S2S handler has its own specific variant for this.
As part of the ongoing refactoring and evolution of the federation code, I
implemented a general-purpose local delivery function: It takes a
LocalRecipientSet and simply delivers to everyone, no handler-specific
assumptions or limitations.
To limit the recipient set according to handler specific rules, just
filter/adapt/edit it before passing to the delivery function.
The function isn't exported yet, but the existing 'deliverLocal' that delivers
only to actors and to author's followers is now implemented via the new
general-purpose function. I hope that's a step towards doing all the local
delivery using this one function, simplifying the complicated federation
code.
I'll use this for C2S to allow client to state who the tracker actor is. It's
still possible to do without it, by HTTP GETing the ticket's context and
checking whether we got an actor, or a non-actor with ticketsTrackedBy. Tbh I'm
adding createTarget simply because it's easier for coding, no need for a custom
variant of actor fetching :P
This allows the context to be specified even when replies/followers/deps/etc.
aren't. This is needed for Create-ing a Ticket. Also, it allows a ticket's
context to be on a different host than where it's hosted, which is also needed
for the Create flow.
A row in this table will be required for local-project-local-author tickets
hosted under the project, and non-existence of a row will be required for such
tickets hosted by the author. So I'll need to CAREFULLY update all the ticket
route handler code and all the ticket related AP code. The latter includes C2S
and S2S for tickets, ticket deps, ticket discussion... everything that is under
tickets.
That's because with the Create flow added, the activity that reports a ticket
can be either Create or Offer, maybe later Announce too.
The old TAL unique name mentioned in the migration has what may look like a
typo, "Locale" instead of "Local". That's because I made a typo in migration
115, and now needed to specify the typoed name I used then. I verified in dev
DB and on dev.angeley.es DB that the typo is reflected in the PostgreSQL
database side and fixed by the new migrations.
Everywhere Ticket is found, a matching LocalTicket is now expected to be found
too. Ticket doesn't point at LocalTicket because there will be remote cached
tickets too. Also, ticket URLs are going to switch the khid from Ticket to
LocalTicket (much like it's already the case for MessageR).
This is a step preparing for the Create flow for tickets. Each Ticket now gets
a matching LocalTicket that points to it. But otherwise the LocalTicket isn't
in use yet.
