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.
