This is an attempt to prevent remote activities from being received in
the wrong order, for example Accept coming before the Add. Whenever that
happens, the add-a-child-parent-link process cannot be completed.
If this doesn't help, another option is to store, per actor, a list of
activities that weren't used, and check them in relevant S2S handlers.
This might have an implication on forwarding if it's time limited (I
don't remember exactly). But worth trying. Example:
- I receive an Accept on an activity I don't recognize
- I store it in that list, for later
- Later I receive an Add activity, which I successfully process
- Now I check that Accept from earlier, seeing if its `object` happens
to be the Add I just received
- If yes, I now process this Accept
A potential problem with this, is that I might accumulate a list of such
activities, and end up hopelessly checking them in every S2S handler.
And I wonde if this is really a healthy elegant approach to the ordering
problem. Maybe some sort of activity numbering can help?
Since collaborator live URIs were using CollabTopic*, this change breaks
existing live URIs, which means all existing delegation chains are now
broken. FYI if you're playing with your own Vervis deployment.
This displays only delegated Grants, not direct ones. Direct ones will
be added in the next commits, as they require some extra changes in the
database.
Until now, a start-Grant could be only a Collab (if it's stand-alone) or
a Stem (if it starts a chain). In other words, either a resource
enabling a direct collaborator, or a component enabling a project that
contains it.
With the new project nesting feature now implemented, there's a new kind
of start-Grant: A child project, once enabled by its parent, sending the
first delegation, giving access-to-self.
This was accidentally not happening until now.
If I, project A, send a start-Grant to my new parent project B, it means
that whoever has access to project B will have access to my settings as
well (for the specific operations their role allows).
Until now I've managed to avoid having to implement this piece quite
easily. The only temptation to implement it has been pseudo-client
features, which are basically just a workaround until Vervis gets a
separate client app.
But now, Person actors need to be able to automatically send
delegator-Grants when they receive a direct-Grant from a resource they
either asked to Join or got an Invite to. So, this creates a need to
track these joins and invites on the server side.
I'm not checking the exact minimal pieces necessary for
delegator-Grants. Instead, I'm starting a full implementation of the
person-side of Collab records (AKA direct-Grants), called Permit
records. This will also allow very convenient display of these Grants
and the extensions received through them, as well as UI buttons such as
accepting/rejecting a received Join or Invite.
Until now, adding a direct collaborator to a Project worked exactly like
with components: Invite or Join, then Accept, finally the direct-Grant.
I missed the fact that much like with project-component relationships,
projects (and teams) need to be able to send extension-Grants to their
direct collaborators.
So in Project's Grant handler it now:
- Recognizes the delegator-Grant coming from a new collaborator
- Sends extension-Grants, using the delegator-Grant as the capability
- When getting a new component and sending extension-Grants for it to
direct collaborators, Project uses their delegator-Grants as
capability
And in Project's Accept handler, it no longer sends extension-Grants
(because it doesn't yet have the collaborator's delegator-Grant at this
point).
NOTE, THIS TEMPORARILY BREAKS grant chains: If you create a Project and
add a Deck to it, you won't get an extension-Grant-for-the-Deck from the
Project, because the Project doesn't yet have your delegator-Grant.
The next commits will implement the Person-side of Collab records, and
will cause Person actors to automatically send the delegator-Grant,
fixing the break.
deckResolve now supports Resolve requests that use extension-Grants. It
iterates the verifies the Grant-chain using the process described in the
ForgeFed specification.
Vervis currently supports only direct grants. The new process supports
delegation chains as well. This commit just implements the new process
as a new function, without yet using it anywhere. The next commits will
plug it into Deck actor handlers.
Ticket closing can now be done via the new C2S, and the "Close ticket"
button on TicketR page is back, and uses that new C2S.
S2S, C2S and pseudo-client are implemented for both Deck and Loom, but
the actual button and POST handler are provided here only for Deck. Will
add ones for Loom soon, as needed.
This is to allow getting rid of the old C2S offerTicketC and write a C2S
Offer handler in the new actor system.
And that is to allow ticket opening and closing to work, so that it can
use delegated OCAPs too, as a first demo of delegated OCAPs in action.
Until now the code GETs the collabs URI to find the resource, but it
didn't make sure the URI was really the collabs URI specified by the
resource. This commit adds the check.
Until now, the resource object itself would be specified. This no longer
works, because it's unclear whether we're adding/removing a collaborator
or a component.
From now on, adding a collaborator is done by pointing to the resource's
'collaborators' URI, not to the resource itself
