Team-Resource Links
2024-07-14 by Pere Lev
The previous posts described project nesting and team nesting. So at that point, it was possible to:
- Create projects with components in them
- Create project hierarchies
- Create teams
- Create team hierarchies
- Add collaborators/members to projects/components/teams
There are still details to polish, of course (e.g. how to link a Repository
with its PatchTracker
), but the core authorization system has been missing
one final piece: Adding teams as collaborators in projects and components.
This piece is now implemented! All the exciting info is below, including a demo.
As always, my task board is available.
Collaboration via Teams
The main purpose of gathering people in Team
actors is to make access control
easier: You create a Backend
team and give this team access to the
backend-related repositories and resources.
Before, we were forming child-parent links between projects, and then between teams. Now there's a new kind of link, in which:
- One side is a
Team
actor - The other side is some resource actor, that isn't a
Team
The resource actors mentioned in the ForgeFed specification (and implemented in Vervis) are:
Project
- The 3 component types:
Repository
,TicketTracker
,PatchTracker
So these resources can now, in addition to regular Person
collaborators, have
Team
collaborators, via the new kind of link.
Team-resource links are created and removed using a mutual-consent process very similar to how parent-child links work, so I won't go into the technical details. See the previous posts for those.
In the UI, here's where I placed team-resource links:
- For teams, there's now a Projects tab (which I'll probably rename to Resources)
- For resources, under the existing Collaborators tab there's a teams section
Bonus: Inbox Debug Reports
Vervis has had some UI for examining the activities received in actor inboxes, and the results of their processing, but this feature was very lacking. In particular:
- Only error messages are shown, while successful processing results aren't
- Only S2S remote activities are shown, on a per-instance page, i.e. local activity results aren't displayed anywhere and actors don't have their own per-actor debug reports
- Activity reports are stored in-memory, which means they disappear when Vervis is restarted
The debug report system recently got an upgrade!
- Actors have their own "errbox", i.e. an inbox displaying activities whose processing resulted with an error
- Actor inbox display shows processing results, whether it's error or success
- The per-instance federated report page grabs activities from the DB, so they don't disappear when Vervis is restarted
This upgrade made my life so much easier, during the work on parent-child and team-resource links.
"Errbox" link for every actor:
Inbox item, including processing result:
Implementation
I started from the DB, UI and API parts, and left the sweet actual S2S implementation for the end. While working on this task, I also polished, fixed and added missing bits for project-component links, which made this task take longer than I hoped (but those bits were important).
The OCAP implementation for components is reusable, but right now only
TicketTracker
is using it. Repository
and PatchTracker
are temporarily
out of the game for now, because I want to figure out the details of linking
them together, as well as the mechanisms for federated-OCAP git-push. Then,
when I see the bigger picture, I'll wire in these components as well. Want to
join the brainstorming on this? Comment on the
issue <3
Team-resource links:
- Specification
- DB
- Vocabulary, serving AP data & UI
- Vocab, UI: Component: Specify and serve teams collection
- UI: Component: POST handlers for team add/approve/remove buttons
- UI: Deck, Group, Project: Enhance collaborators view, prepare to add teams
- UI: Repo, Loom: Update collaborators view & buttons, similar to Deck
- UI: Component, Project: Display teams, invites and action buttons
- UI, Vocab: Group: Serve accessible resources collection
- UI: Group: POST handlers for resource add-approve-remove buttons
- UI: Group: Display resources, invites and action buttons
- Serve live URIs for Team (Squad) records for project, repo, deck, loom
- UI: Repo, Loom: Project add-approve-remove buttons
- Serve AP version of component projects collection
- S2S logic for Team)
- S2S: Group: Grant: Extend Grants from my projects
- S2S: Group: Add: Implement resource-active mode
- S2S: Group: Add: Implement resource-passive mode
- S2S: Group: Accept: Implement resource mode
- S2S: Group: Accept: Implement remove-resource mode
- S2S: Group: Grant: Implement resource mode
- S2S: Group: Remove: Implement resource-active mode
- S2S: Group: Remove: Implement resource-passive mode
- S2S: Group: Revoke: Implement resource mode
- S2S logic for Project and components
- S2S: Project: Revoke: Implement component & team modes
- S2S: Project: Accept: When removing a child, revoke extensions to teams
- S2S: Project: Grant: When adding component/child, extend Grant to teams
- S2S: Project: Revoke: Collab: Delete and send Revokes on extensions
- S2S: Project: Remove: Child-active: Revoke Grants-for-teams
- S2S: Component: Implement Revoke handler
- S2S: Project: Add: Implement team mode
- S2S: Project: Accept: Implement team mode
- S2S: Project: Grant: Implement team mode
- S2S: Project: Remove: Implement team mode
- S2S: Component: Add: Port team-mode from Project
- S2S: Component: Accept: Port team-mode from Project
- S2S: Component: Grant: Port team-mode from Project
- S2S: Component: Remove: Port team-mode from Project
Inbox debug reports:
- S2S, DB: Store processing result in InboxItem record
- UI: Inbox: For each item, display the result of processing
- DB: Give each actor a secondary inbox, for collecting errors
- UI: Error-inbox ("Errbox") display for all local actors
- UI, DB: Store debug reports in DB and link to them from navbar
Funding
I really want to thank NLnet for funding this work! The extended grant is allowing me to continue backend work, and allowing AndrΓ© to work on the Anvil frontend.
Next Steps
Meanwhile, the Anvil frontend is making progress as well:
The previous blog post has a list of challenges waiting ahead. With the core OCAP system complete, I'm now looking at the list of remaining funded tasks. There's primarily 3 kinds of tasks:
- Documentation, API and bug-fixing, to support Anvil's development, and the deployment of a Vervis-Anvil federated forges
- Actor-programming library and demo (much more powerful than the current ActivityPub-based OCAPs, and I believe necessary for the growing federated ecosystem)
- Vervis core features for
Repository
andPatchTracker
The 2nd kind is the most difficult for me: Create a powerful type-safe actor-programming library in the Haskell programming language. I already started this, probably over a year ago, but haven't touched that work in a long time. And it's quite advanced Haskell (at least for me). Luckily there's already work by another NLnet-funded project, and the Haskell implementation of Cap-n-Proto, which I hope to reuse.
In the coming months I hope to touch all of those tasks. But I'm not sure yet how to divide my time and focus between them. I'm especially afraid to spend a lot of time on the actor-programming library, and end up failing. I really need the income right now, so working on safer tasks is easier. On the other hand, much of my remaining funds are for the library. We'll see :)
See It in Action
I recorded a little demo of all this! Watch it on my PeerTube instance.
If you want to play with things yourself, you can create account(s) on the demo instances - fig, grape, walnut - and try the things I've mentioned and done in the video.
If you encounter any bugs, let me know! Or open an issue
Comments
Come chat with us on Matrix!
And we have an account for ForgeFed on the Fediverse: https://floss.social/@forgefed
Right after publishing this post, I'll make a toot there to announce the post, and you can comment there :)