Skip to content

Add awareness widget to issue sidebar

Hannes Moser requested to merge feature-awareness into master

What does this MR do and why?

Adds a "collaborator" widget to the issue sidebar.

Collaborators are user avatars, organized in a "face stack", that allow issue viewers and editors to see who currently is looking or editing the same issue. As the sidebar is only available for issues that were persisted at least once, this feature is not available for issues that are in the process of being created.

A collaborator can have two distinct states:

  • Present (active user)
  • Away (inactive user)

The presence is defined by the users' activity within the last five minutes. If there was no interaction between the user and the issue (window/tab becomes active, etc.), the user is marked away.

A touch action can be performed by the client to signal the server that the user is still active.

Resolves gitlab-org/incubation-engineering/real-time-editing/real-time-editing-issue-descriptions#1.

  • Needs !95047 (merged) to be merged first.
  • Create issue for feature flag (rollout)

Screenshots or screen recordings

All possible states where all collaborators are present (active)

Screen_Shot_2022-08-16_at_12.03.15 Screen_Shot_2022-08-16_at_12.03.27 Screen_Shot_2022-08-18_at_10.37.26 Screen_Shot_2022-08-18_at_10.37.28 Screen_Shot_2022-08-18_at_10.37.14 Screen_Shot_2022-08-18_at_10.37.11 Screen_Shot_2022-08-18_at_10.37.02 Screen_Shot_2022-08-18_at_10.36.56 Screen_Shot_2022-08-18_at_10.29.14

Some collaborators are marked away (inactive)

Please note how active/inactive users are grouped together.

Screen_Shot_2022-08-18_at_10.36.49 Screen_Shot_2022-08-18_at_10.36.56 Screen_Shot_2022-08-18_at_10.37.14

How to set up and validate locally

  1. Enable the feature flag for awareness in issues
Feature.enable(:awareness_for_issues)
  1. Create a new issue with the administrator account. It is best to create a new project for this (with an easy to remember name).
  2. Create at least 4 (5 or 6 are better) new local users (in addition to the always existing root/administrator account) which all need access to the newly created issue. For example:
  • awareness1:supersecret
  • awareness2:supersecret
  • awareness4:supersecret
  • awarenessN:supersecret
  1. You need 3 browsers to test (Chrome, Firefox, Safari for example) Session cookies are shared even between incognito tabs, you need to make sure to sign in with a clean browser environment.
  2. Sign in with the individual users on every browser. Use one regular and one incognito window/tab
  3. Open/Close tabs: You should see collaborators appear/disappear in the other windows/tabs
  4. Hover over avatar: You should see the username and the last known activity timestamp rendered in a human-readable format
  5. Hover over the "more" placeholder: You should see a vertical list of avatars that are also present in the session. They do not have a present/away status! If the list grows to a larger audience than 5-6, it switches into scroll mode within the popover. This is particularly hard to test, because we can't really sign in with so many local users easily. You can test this specific behavior by copy & pasting the for loop in the collaborator_more.vue component.
        <gl-avatar-labeled
          v-for="collaborator in collaborators"
          :key="collaborator.id"
          :size="32"
          :src="collaborator.avatar_url || collaborator.avatarUrl"
          :label="collaborator.name"
          :sub-label="collaborator.name"
        />
        <gl-avatar-labeled
          v-for="collaborator in collaborators"
          :key="collaborator.id"
          :size="32"
          :src="collaborator.avatar_url || collaborator.avatarUrl"
          :label="collaborator.name"
          :sub-label="collaborator.name"
        />
        <gl-avatar-labeled
          v-for="collaborator in collaborators"
          :key="collaborator.id"
          :size="32"
          :src="collaborator.avatar_url || collaborator.avatarUrl"
          :label="collaborator.name"
          :sub-label="collaborator.name"
        />

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Hannes Moser

Merge request reports