Groups

We're solving two primary use-cases with socra: personal use, and use within groups/teams. Personal

We're solving two primary use-cases with socra: personal use, and use within groups/teams. ## Personal Each user has a personal "space" (AKA root node). Within this space, a user can organize his or her projects, folders, socras, etc. Users can share items or folders within their personal space in a one-off basis, and permissions for new child nodes are always inherited from parents. Because users are added on a one-off bases, we need to limit the number of individual users that can be added to a tree node contained within a personal workspace. The limit should be on the order of ~50 or so. ## Group/Team Groups and teams satisfy a different use-case, where a team or group wants to collectively move the bar forward on a particular mission. When a group is created, we'll automatically create a "space" (AKA root node) for the team. Within this space, a group can organize their projects, folders, socras, etc. Since we only need to create a single permission for each tree node contained within a group space, we can add many more users to a group than we can an individual item in a personal space. My suggestions for groups: - Users must be a member of the group to see any nodes within the group. This will effectively prevent adding users to items individually, at the expense of ensuring everyone within the group can see everything in the group. - Groups should have a stated mission/description, binding a group to a purpose ## Projects, Goals, Tasks, and Chats (Oh my!) Projects and Goals should be different node types to help organize nodes within a space. Projects can have Goals, and Goals can have Projects. ### Projects - Folders should be reserved to hold files and sub-folders. - Projects should be reserved to hold sub-projects, tasks and folders/files. - socras should be completed within projects? - Projects can have sub-projects - Projects care about the order of completion. This means we need some way to show the "order" of items to be completed, either in inbox view or elsewhere (not just most recent) - timeline for a project should show the history of the project. ### Goals - A goal is a stated mission/something a user or group wants to achieve. - Goals can have Projects, and Projects can have Goals. - Timeline for a Goal should show progress toward the goal ### Chats - Chats should be used to figure out something quickly, either with a teammate or with an AI. - [x] Implement core backend for Group and GroupMember - [x] models - [x] serializers - [x] managers - [x] testing - [x] Integrate groups into socra queryset - [x] modify managers - [x] test - [x] Frontend - [x] Move all settings into a single "settings" tab in control dialog/center - [x] Change notifications to show pending requests - [x] Add filter by group, which will show all socras a particular group has access to. Pretty handy Need to find a better way of determining user's highest role for a given socra. - currently, we iterate through all permissions and find permission of type user for the user. Then we run through role order and determine the user's highest role for a socra. - If we do the same with groups, we'll need to know all of a user's groups in advance of finding capabilities. - Alternatively, we could somehow annotate the queryset with the user's highest role - e.g. annotate is_viewer, is_commenter, is_editor, is_admin, is_owner - Downside of this approach is that we'll end up with quite a few queries. - or, somehow rank the roles and find the largest role - For now, let's fetch the user's groups and find highest role by iterating through the groups. - Hopefully, we can cache the user's groups. List of groups exist on nav. When a group is clicked, right panel shows members, inbox shows socras that group has access to. Extremely simple list item, just avatar and name. Separate into Owner, Admin, Members. Requests above Thoughts (6/15) - What functionality are we enabling with groups? - Ability to grant tree node access to many people at once. - Use-cases: - Creating a group specifically for testers - For each group, we should be able to see all shared source journeys - This means we can click on a group, and when clicked, the shared source journeys will expand under the group - Group context menu should contain user capabilities relative to the group: - Manage - Leave - Should be able to pin a group (pins are per-user) - Can pin up to 10 groups - New Group button similar to new journey button Nav query - For general nav, user Tree performs the work of fetching display roots, expanded ids, and so on. - For groups, our goal is to show all groups as a list, and under each group, show display roots for the group (nodes that are shared source nodes for the group) - This means we may end up showing the same folder in multiple places. This is OK as long as expanding the folder in one tree does not expand it in another - This also means we should limit the number of groups a user can be part of, so that we can fetch all groups at the same time (or a "show more" button) - Final solution: - GroupsContext should auto-fetch groups if groups nav item is expanded, or fetch when groups nav item is expanded - Each group contains an independent tree of display roots. When a group is clicked, the display roots for the group are fetched. Note that the same tree node can be shared with one or more groups, so expanding a tree node within one group should not affect that tree node in another group - Each GroupTree should register listeners for socra created/updated/deleted so that we can add/update nodes as needed (use permissions of the tree nodes to determine if events should be responded to, and we should only respond to events that affect the visibility of nodes already expanded in the tree. - If group(s) query parameter is provided on refresh, we should attempt to auto-expand the group tree(s) to the selected tree node. This will be challenging.

By Mike Morton