forgefed/content/blog/teams.md

+++ title = "Teams" date = 2023-12-09 [extra] author = "Pere Lev" +++

So far, we've mostly been playing here with Ticket Trackers and Projects. Teams are now joining the OCAP game as well.

After the words there's a visual demo as well.

Take a look at my task board (and the previous blog posts) for more context while reading.

Access Management Overview

The ForgeFed specification and the Vervis implementation have had 2 pieces of the access management puzzle:

• Adding direct collaborators to resources (such as Ticket Trackers and Projects)
• Adding components (such as Ticket Trackers) to Projects

To proceed from there, there are preparation steps:

• Implementing the missing basics for the Team actor
• Implementing adding-direct-collaborators for Teams

The rest of the pieces are:

• Allowing projects to have parents and children
• Allowing teams to have parents and children
• Allowing teams to have access to components
• Allowing teams to have access to projects

This blog post is introducing the 2 preparation steps.

The Team Actor

Software developers can gather in teams. Teams have existed in the Vervis DB schema for a long time, but their old original pre-federation implementation became irrelevant. I've created an updated, OCAP-ready implementation, which includes team creation, viewing and browsing, which is task V4 on my task list, in the following commits:

• Vocabulary and View
• C2S handlers for team creation
• S2S handlers for team creation
• Port basic S2S handlers adapted from Project actors
• Team creation UI and additional displays

You'll see this stuff in action in the demo below.

Authorized Chain Extensions

With team basics in place, I proceeded to tasks V6 and S2, which are about adding and removing team members. While examining my control flow diagrams, I noticed a piece missing, that seemed important to implement first.

When a direct collaborator is added to a component (e.g. a ticket tracker), the activity flow is simple:

1. An offer is made, to add a new collaborator
2. The component approves the validity of the offer
3. The candidate collaborator accepts the offer
4. The components sends the collaborator a Grant activity

However, for Projects and for Teams, there's an additional part: They need to be able to send extension Grants to the collaborator. They receive access privileges from their components/child projects/parent teams, and they need to be able to forward these privileges to the collaborator.

The additional part was already implemented, but it was missing the "delegator-Grant" step: A special Grant activity giving the privilege to do the forwarding mentioned above. I recently added that missing bit to the specification, and decided it's a good timing to implement it, since Teams are going to need it as well. I'm calling it "authoried chain extensions", because the OCAP chain extensions now become authorized via a delegator-Grant, instead of being sent without context.

Implementing that delegator-Grant piece involved 2 parts:

• Track delegator-Grants on the Project/Team side
• Track the entire OCAP flow on the Person actor side (which I haven't done at all until now, because it wasn't needed on the server)

I thus upgraded the OCAP-chain tracking system for Projects and Teams, adding that delegator-Grant piece, in the following commits:

• DB: here here, and here
• S2S: here, here, here, here and here
• C2S: here, here and here

Team Membership

With those pieces in place, I proceeded to implementing the actual Activity handlers for the Team actor to enable the direct-collaborator flow, which is how team member addition and removal work behind the scenes. And of course I added UI for team member addition and removal.

• Specification:
  • The process of adding/removing people to/from teams was documented together with the process for Projects, in PR #210 which I mentioned in the previous blog post (and in the tasks related to it)
  • There's also the new PR #214 which adds details specific to teams
• S2S: Team: Implement direct-collaborator flow, adapted from Project
• UI: Team: Buttons and form for adding and removing members
• UI: Display personal resources using Permit records
• UI: For each Permit, display delegator-Grant and extensions
• UI: Dashboard: Display personal invites
• UI: Dashboard: Add 'Accept' button to invites you haven't yet accepted

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:

• Creating teams
• Inviting a collaborator
• Accepting the invite
• As the new collaborator, using the access granted by the team (which right now is limited to adding (or removing) more collaborators, until more pieces of the system are implemented in the next tasks)

If you encounter any bugs, let me know! Or open an issue

Comments

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 :)