@plone-collective/volto-identity 1.0.0-alpha.1

package/src/components/UserMenu/UserMenuPlugs.test.tsx

@@ -0,0 +1,202 @@
+/**
+ * The personal-tools menu as an ordered list of plugs.
+ *
+ * The entries are registered from five separate components, so what nobody
+ * can see by reading any one of them is the thing worth testing: what the
+ * assembled menu contains, in what order, and which entries stand each other
+ * down.
+ */
+import { describe, expect, it, vi } from 'vitest';
+import { fireEvent, render, screen } from '../../testing';
+import { MemoryRouter } from 'react-router-dom';
+import { Provider } from 'react-redux';
+import React from 'react';
+
+import {
+  Pluggable,
+  PluggablesProvider,
+} from '@plone/volto/components/manage/Pluggable';
+import IdentitiesMenuItem from './IdentitiesMenuItem';
+import ProfileMenuItem from './ProfileMenuItem';
+import {
+  PersonalInformationMenuItem,
+  PreferencesMenuItem,
+  SiteSetupMenuItem,
+} from './UserMenuPlugs';
+
+interface MenuState {
+  /** The Profile URL `@users` reported, when the user has one. */
+  profileUrl?: string | null;
+  /** The PAS plugin the userid came from, as `@users` reports it. */
+  source?: string | null;
+  /** The user actions the backend listed. */
+  actions?: unknown[];
+  /** Slide a panel in; the prop `PersonalTools` passes through params. */
+  loadComponent?: (selector: string) => void;
+}
+
+/**
+ * Render the whole menu the way the application assembles it.
+ *
+ * Every plug is mounted from `appExtras` in the real thing, which is what
+ * this stands in for; the `<Pluggable>` is what the shadowed `PersonalTools`
+ * renders.
+ *
+ * @param state What the store says and what the toolbar passes down.
+ * @returns The ids of the entries, in the order they were rendered.
+ */
+function renderMenu(state: MenuState = {}) {
+  const {
+    profileUrl = null,
+    source = null,
+    actions = [],
+    loadComponent = vi.fn(),
+  } = state;
+  const store = {
+    getState: () => ({
+      userProfile: { data: { id: 'alice', profile_url: profileUrl, source } },
+      actions: { actions: { user: actions } },
+    }),
+    dispatch: vi.fn(),
+    subscribe: () => () => {},
+  };
+
+  render(
+    <Provider store={store as never}>
+      <MemoryRouter>
+        <PluggablesProvider>
+          <PersonalInformationMenuItem />
+          <PreferencesMenuItem />
+          <SiteSetupMenuItem />
+          <IdentitiesMenuItem />
+          <ProfileMenuItem />
+          <ul>
+            <Pluggable name="toolbar-user-menu" params={{ loadComponent }} />
+          </ul>
+        </PluggablesProvider>
+      </MemoryRouter>
+    </Provider>,
+  );
+
+  return {
+    loadComponent,
+    ids: Array.from(document.querySelectorAll('li > *')).map((el) => el.id),
+  };
+}
+
+/** A user whose account *is* a Profile content object. */
+const STORED_AS_A_PROFILE: MenuState = {
+  profileUrl: 'http://site/profiles/alice',
+  source: 'identity_profile',
+};
+
+describe('the personal-tools menu', () => {
+  it('puts sign-in methods straight after preferences', () => {
+    // Which is where it belongs: choosing how you get in is a preference,
+    // and before this the pluggable could only append after Site Setup.
+    const { ids } = renderMenu();
+
+    expect(ids).toEqual([
+      'toolbar-profile',
+      'toolbar-preferences',
+      'toolbar-identities',
+    ]);
+  });
+
+  it('puts Site Setup last, for somebody who has that action', () => {
+    // Last because it is about the site rather than about the person.
+    const { ids } = renderMenu({ actions: [{ id: 'plone_setup' }] });
+
+    expect(ids[ids.length - 1]).toBe('toolbar-site-setup');
+  });
+
+  it('offers Site Setup to nobody else', () => {
+    const { ids } = renderMenu();
+
+    expect(ids).not.toContain('toolbar-site-setup');
+  });
+
+  it('gives the Profile slot to the object the account lives in', () => {
+    // Not beside it: two entries both called "Profile" make the reader guess
+    // which one they want.
+    const { ids } = renderMenu(STORED_AS_A_PROFILE);
+
+    expect(ids).toContain('toolbar-identity-profile');
+    expect(ids).not.toContain('toolbar-profile');
+  });
+
+  it('keeps it where the member form was', () => {
+    const { ids } = renderMenu(STORED_AS_A_PROFILE);
+
+    expect(ids).toEqual([
+      'toolbar-identity-profile',
+      'toolbar-preferences',
+      'toolbar-identities',
+    ]);
+  });
+
+  it('calls it Profile either way', () => {
+    // It stands in the other one's place rather than beside it, so it takes
+    // its name too.
+    renderMenu(STORED_AS_A_PROFILE);
+    expect(screen.getByText('Profile')).toBeTruthy();
+
+    document.body.innerHTML = '';
+    renderMenu();
+    expect(screen.getByText('Profile')).toBeTruthy();
+  });
+
+  it('does not care which plugin authenticated the account', () => {
+    // `source` names whichever plugin PAS enumerated the account from, and
+    // that changes with how the account was made -- so a rule keyed on it
+    // hid the entry for whole classes of user. `profile_url` is the
+    // question the menu actually has.
+    const { ids } = renderMenu({
+      profileUrl: 'http://site/profiles/alice',
+      source: 'source_users',
+    });
+
+    expect(ids).toContain('toolbar-identity-profile');
+    expect(ids).not.toContain('toolbar-profile');
+  });
+
+  it('falls back to the member form when there is no Profile', () => {
+    // An account that predates the add-on, or a user whose first login has
+    // not minted a Profile yet.
+    const { ids } = renderMenu();
+
+    expect(ids).toContain('toolbar-profile');
+    expect(ids).not.toContain('toolbar-identity-profile');
+  });
+
+  it('needs a Profile to link to', () => {
+    // A menu entry leading nowhere is worse than no menu entry.
+    const { ids } = renderMenu({ source: 'identity_profile' });
+
+    expect(ids).toContain('toolbar-profile');
+    expect(ids).not.toContain('toolbar-identity-profile');
+  });
+
+  it('gives every entry an id that does not change with the language', () => {
+    // Upstream used the translated label as the DOM id, so anything keying
+    // on it worked in English and silently not in Portuguese.
+    const { ids } = renderMenu({
+      ...STORED_AS_A_PROFILE,
+      actions: [{ id: 'plone_setup' }],
+    });
+
+    for (const id of ids) {
+      expect(id.startsWith('toolbar-')).toBe(true);
+    }
+  });
+
+  it('slides the preferences panel in through the toolbar it came from', () => {
+    // The one entry that is not a link. `loadComponent` belongs to
+    // `PersonalTools`, and reaches this plug through the pluggable's params.
+    const { loadComponent } = renderMenu();
+
+    fireEvent.click(screen.getByRole('button', { name: 'Preferences' }));
+
+    expect(loadComponent).toHaveBeenCalledWith('preferences');
+  });
+});

package/src/components/UserMenu/UserMenuPlugs.tsx

@@ -0,0 +1,142 @@
+/**
+ * Volto's own personal-tools entries, re-registered as plugs.
+ *
+ * The menu used to be three entries written into `PersonalTools` plus a
+ * pluggable at the end, which meant an add-on could only ever *append*: a
+ * site wanting "Sign-in methods" under "Preferences", or wanting no "Site
+ * Setup" link, had to shadow the component again. Here every entry is a plug
+ * with an `order`, including the ones Volto ships, so the whole menu is one
+ * ordered list a site composes rather than three fixed things and a bucket.
+ *
+ * The orders are spaced by ten, so an add-on can land between two of them
+ * without renumbering anything:
+ *
+ * ==== ==========================================================
+ *   10 The profile -- this package's, when the user has one;
+ *      Volto's member form otherwise. Never both: see below.
+ *   20 Preferences
+ *   30 Sign-in methods, which is asked for right after preferences
+ *      because it *is* a preference: it is where a person adds or
+ *      drops a way of getting in.
+ *   35 Applications, on a site running the `[server]` layer -- the
+ *      same question the other way round, so it sits next to it.
+ *      A number between two of these is exactly what the spacing
+ *      is for.
+ *   40 Site Setup, for a manager. Last because it is about the
+ *      site rather than about the person.
+ * ==== ==========================================================
+ *
+ * `loadComponent` reaches these through the pluggable's `params`, which is
+ * how a plug rendered from `appExtras` gets at a prop that belongs to
+ * `PersonalTools`. A plug that needs it takes a function child; one that does
+ * not takes plain children and never sees them.
+ * @module components/UserMenu/UserMenuPlugs
+ */
+import React from 'react';
+import { useSelector } from 'react-redux';
+import { defineMessages, useIntl } from 'react-intl';
+import { Plug } from '@plone/volto/components/manage/Pluggable';
+
+import { profileHoldsTheFields } from '../../helpers/profileSource';
+import MenuItem from './MenuItem';
+
+const messages = defineMessages({
+  preferences: { id: 'Preferences', defaultMessage: 'Preferences' },
+  profile: { id: 'Profile', defaultMessage: 'Profile' },
+  siteSetup: { id: 'Site Setup', defaultMessage: 'Site Setup' },
+});
+
+/** Params the personal-tools pluggable hands to every plug. */
+export interface UserMenuParams {
+  /** Slide another panel into the toolbar, by its registered name. */
+  loadComponent: (selector: string) => void;
+}
+
+/**
+ * Volto's own Profile entry, which is the member form at
+ * `/personal-information`.
+ *
+ * Absent for a user whose fields are held in a Profile, where
+ * `ProfileMenuItem` takes this slot under the same name. It keeps the slot
+ * for a user first login has not minted a Profile for, and for an account
+ * that predates the add-on -- who are exactly the users whose fields really
+ * are edited at `/personal-information`.
+ */
+export const PersonalInformationMenuItem: React.FC = () => {
+  const intl = useIntl();
+  // A primitive; see `ProfileMenuItem` for why.
+  const profileUrl = useSelector(
+    (state: any) => state.userProfile?.data?.profile_url,
+  );
+
+  if (profileHoldsTheFields(profileUrl)) {
+    return null;
+  }
+
+  return (
+    <Plug
+      pluggable="toolbar-user-menu"
+      id="personal-information"
+      order={10}
+      dependencies={[profileUrl]}
+    >
+      <MenuItem
+        id="toolbar-profile"
+        label={intl.formatMessage(messages.profile)}
+        to="/personal-information"
+      />
+    </Plug>
+  );
+};
+
+/** Volto's Preferences panel, which slides in rather than being a route. */
+export const PreferencesMenuItem: React.FC = () => {
+  const intl = useIntl();
+  return (
+    <Plug pluggable="toolbar-user-menu" id="preferences" order={20}>
+      {({ loadComponent }: UserMenuParams) => (
+        <MenuItem
+          id="toolbar-preferences"
+          label={intl.formatMessage(messages.preferences)}
+          onClick={() => loadComponent('preferences')}
+        />
+      )}
+    </Plug>
+  );
+};
+
+/**
+ * Volto's Site Setup link, for a user who may see it.
+ *
+ * The condition is upstream's: the `plone_setup` user action, which the
+ * backend only lists for somebody allowed to reach the control panels. Read
+ * from the store here rather than passed through `params`, so this plug does
+ * not need `PersonalTools` to know about it.
+ */
+export const SiteSetupMenuItem: React.FC = () => {
+  const intl = useIntl();
+  const siteSetupAction = useSelector((state: any) =>
+    state.actions?.actions?.user?.find(
+      (action: { id?: string }) => action?.id === 'plone_setup',
+    ),
+  );
+
+  if (!siteSetupAction) {
+    return null;
+  }
+
+  return (
+    <Plug
+      pluggable="toolbar-user-menu"
+      id="site-setup"
+      order={40}
+      dependencies={[Boolean(siteSetupAction)]}
+    >
+      <MenuItem
+        id="toolbar-site-setup"
+        label={intl.formatMessage(messages.siteSetup)}
+        to="/controlpanel"
+      />
+    </Plug>
+  );
+};

package/src/components/UserMenu/UserProfileLoader.test.tsx

@@ -0,0 +1,211 @@
+import { describe, expect, it, vi } from 'vitest';
+import { render } from '../../testing';
+import { Provider } from 'react-redux';
+import React from 'react';
+
+import UserProfileLoader from './UserProfileLoader';
+
+/** A JWT-shaped token whose payload names `sub`. */
+function tokenFor(sub: string): string {
+  const body = Buffer.from(JSON.stringify({ sub, exp: 9e9 }))
+    .toString('base64')
+    .replace(/\+/g, '-')
+    .replace(/\//g, '_')
+    .replace(/=+$/, '');
+  return `header.${body}.signature`;
+}
+
+function renderLoader(state: Record<string, unknown>) {
+  const dispatch = vi.fn((action: unknown) => action);
+  const store = {
+    getState: () => state,
+    dispatch,
+    subscribe: () => () => {},
+  };
+  render(
+    <Provider store={store as never}>
+      <UserProfileLoader />
+    </Provider>,
+  );
+  return dispatch;
+}
+
+const EMPTY = { loading: false, loaded: false, error: null, data: null };
+
+describe('UserProfileLoader', () => {
+  it('asks for the signed-in user', () => {
+    const dispatch = renderLoader({
+      userSession: { token: tokenFor('alice') },
+      userProfile: EMPTY,
+    });
+
+    expect(dispatch).toHaveBeenCalledWith(
+      expect.objectContaining({
+        request: { op: 'get', path: '/@users/alice' },
+      }),
+    );
+  });
+
+  it('asks for nothing when nobody is signed in', () => {
+    const dispatch = renderLoader({
+      userSession: { token: '' },
+      userProfile: EMPTY,
+    });
+
+    expect(dispatch).not.toHaveBeenCalled();
+  });
+
+  it('does not ask again for a user it already holds', () => {
+    const dispatch = renderLoader({
+      userSession: { token: tokenFor('alice') },
+      userProfile: {
+        loading: false,
+        loaded: true,
+        error: null,
+        data: { id: 'alice' },
+      },
+    });
+
+    expect(dispatch).not.toHaveBeenCalled();
+  });
+
+  it('does not ask while a request is in flight', () => {
+    const dispatch = renderLoader({
+      userSession: { token: tokenFor('alice') },
+      userProfile: { ...EMPTY, loading: true },
+    });
+
+    expect(dispatch).not.toHaveBeenCalled();
+  });
+
+  it('asks again when a different user signs in', () => {
+    const dispatch = renderLoader({
+      userSession: { token: tokenFor('bob') },
+      userProfile: {
+        loading: false,
+        loaded: true,
+        error: null,
+        data: { id: 'alice' },
+      },
+    });
+
+    expect(dispatch).toHaveBeenCalledWith(
+      expect.objectContaining({
+        request: { op: 'get', path: '/@users/bob' },
+      }),
+    );
+  });
+
+  it('survives a store where nothing has been initialised yet', () => {
+    // Both slices are read with optional chaining because this mounts on
+    // every route, including the first render of a cold store.
+    const dispatch = renderLoader({});
+
+    expect(dispatch).not.toHaveBeenCalled();
+  });
+
+  it('does not retry forever after a failure', () => {
+    // The request was refused -- 401 on a stale token, say. Retrying on
+    // every render would be a request per frame.
+    const dispatch = renderLoader({
+      userSession: { token: tokenFor('alice') },
+      userProfile: {
+        loading: false,
+        loaded: false,
+        error: { status: 401 },
+        data: null,
+      },
+    });
+
+    expect(dispatch).toHaveBeenCalledTimes(1);
+  });
+
+  it('does not ask again after the request failed', () => {
+    // The storm, reproduced the way it actually happened: the request fails,
+    // `loading` goes true then false again, and a guard made only of
+    // `loading` and `loadedFor` is satisfied on the very next render. One
+    // render cannot show this — the effect has to re-run, which is what the
+    // oscillation below causes.
+    const dispatch = vi.fn((action: unknown) => action);
+    const state: Record<string, unknown> = {
+      userSession: { token: tokenFor('alice') },
+      userProfile: { ...EMPTY },
+    };
+    const store = {
+      getState: () => state,
+      dispatch,
+      subscribe: () => () => {},
+    };
+    const { rerender } = render(
+      <Provider store={store as never}>
+        <UserProfileLoader />
+      </Provider>,
+    );
+
+    // Three failed round trips' worth of state changes.
+    for (const loading of [true, false, true, false, true, false]) {
+      state.userProfile = loading
+        ? { loading: true, loaded: false, error: null, data: null }
+        : { loading: false, loaded: false, error: { status: 401 }, data: null };
+      rerender(
+        <Provider store={{ ...store, getState: () => state } as never}>
+          <UserProfileLoader />
+        </Provider>,
+      );
+    }
+
+    expect(dispatch).toHaveBeenCalledTimes(1);
+  });
+
+  it('does not ask again after a failure it already saw', () => {
+    // The storm. A failed request leaves `loadedFor` unset and `loading`
+    // false, so a guard made only of those two is satisfied on the very next
+    // render and the effect fires again — for ever. A token that no longer
+    // authenticates but still decodes to a userid, which is exactly what a
+    // stale token against a rebuilt site is, produced about 150 requests a
+    // second against `@users/<id>` in the demo until the tab was closed.
+    const dispatch = renderLoader({
+      userSession: { token: tokenFor('alice') },
+      userProfile: {
+        loading: false,
+        loaded: false,
+        error: { status: 401 },
+        data: null,
+      },
+    });
+
+    expect(dispatch).toHaveBeenCalledTimes(1);
+  });
+
+  it('asks again when the user changes', () => {
+    // One attempt per userid, not one attempt ever: signing in as somebody
+    // else has to fetch somebody else.
+    const dispatch = renderLoader({
+      userSession: { token: tokenFor('alice') },
+      userProfile: {
+        loading: false,
+        loaded: false,
+        error: { status: 401 },
+        data: null,
+      },
+    });
+    const first = dispatch.mock.calls.length;
+
+    const second = renderLoader({
+      userSession: { token: tokenFor('bob') },
+      userProfile: {
+        loading: false,
+        loaded: false,
+        error: { status: 401 },
+        data: null,
+      },
+    });
+
+    expect(first).toBe(1);
+    expect(second).toHaveBeenCalledWith(
+      expect.objectContaining({
+        request: { op: 'get', path: '/@users/bob' },
+      }),
+    );
+  });
+});

package/src/components/UserMenu/UserProfileLoader.tsx

@@ -0,0 +1,54 @@
+/**
+ * Keep the signed-in user's profile in the store.
+ *
+ * Volto fetches the current user only when the personal-tools menu opens, and
+ * what it fetches lands in `state.users.user`, which the menu also clears
+ * around itself. Anything that wants to show who is signed in *outside* that
+ * menu -- an avatar in the toolbar, a link to the user's Profile -- therefore
+ * cannot rely on it being there.
+ *
+ * This mounts on every route through `appExtras`, renders nothing, and asks
+ * once per userid — once, whether the answer arrives or fails. It is the userid rather than the token that it keys on:
+ * a token is reissued on refresh without the user changing, and refetching
+ * the same person on every renewal would be a request per hour for nothing.
+ * @module components/UserMenu/UserProfileLoader
+ */
+import React, { useEffect, useRef } from 'react';
+import { useDispatch, useSelector } from 'react-redux';
+
+import { getUserProfile } from '../../actions';
+import { useridFromToken } from '../../helpers/token';
+
+const UserProfileLoader: React.FC = () => {
+  const dispatch = useDispatch();
+  const token = useSelector((state: any) => state.userSession?.token);
+  const loadedFor = useSelector((state: any) => state.userProfile?.data?.id);
+  const loading = useSelector((state: any) => state.userProfile?.loading);
+  const userid = useridFromToken(token);
+  const attempted = useRef<string | null>(null);
+
+  useEffect(() => {
+    // Anonymous, or already holding this user. A request in flight counts as
+    // holding them: without that check the effect fires again on the render
+    // the pending state causes, and the two answers race.
+    if (!userid || loading || loadedFor === userid) {
+      return;
+    }
+    // And once per userid, however it turned out. A *failed* request leaves
+    // `loadedFor` unset and `loading` false, so the two checks above are both
+    // satisfied on the very next render and the effect fires again — for
+    // ever. A token that no longer authenticates but still decodes to a
+    // userid, which is what a stale token in a rebuilt site is, produced
+    // about 150 requests a second against `@users/<id>` until the tab was
+    // closed.
+    if (attempted.current === userid) {
+      return;
+    }
+    attempted.current = userid;
+    dispatch(getUserProfile(userid));
+  }, [dispatch, userid, loadedFor, loading]);
+
+  return null;
+};
+
+export default UserProfileLoader;

package/src/components/Views/GroupView.scss

@@ -0,0 +1,36 @@
+/**
+ * A group page: what is in it, and who.
+ *
+ * Three sections with the same rhythm, so a group nested three deep and a
+ * flat one read as the same page with different amounts on it.
+ */
+.identity-group-view {
+  section {
+    margin-top: var(--identity-gap);
+  }
+
+  h2 {
+    margin-bottom: 4px;
+    font-size: 1.15em;
+  }
+
+  ul {
+    padding: 0;
+    margin: 8px 0 0;
+    list-style: none;
+  }
+
+  li {
+    display: flex;
+    align-items: baseline;
+    padding: 6px 0;
+    border-bottom: var(--identity-border);
+    gap: 8px;
+  }
+}
+
+.identity-group-view__list {
+  li a {
+    font-weight: 600;
+  }
+}