Skip to content

C
coopwire-hypothesis
Switch branch/tag
  1. 04 Nov, 2024 6 commits
  3. 30 Oct, 2024 2 commits
    • Robert Knight's avatar
      Update `allowLeavingGroups` docs to match reality · 2522dc18
      Robert Knight authored 
      Update the documentation to match the current behavior. As noted in
https://github.com/hypothesis/client/pull/6638, the code comments and behavior
were inconsistent. Since changing the behavior is potentially disruptive, that
PR changed the comments instead. This commit updates the publisher-facing
documentation.
      2522dc18
    • Robert Knight's avatar
      Show "Leave group" option for open and restricted groups that user is a member of · d14c255b
      Robert Knight authored 
      Previously the "Leave group" option was only shown for private groups on the
basis that membership of open and restricted groups was managed by h admins.
However first-party Hypothesis users can now create open and restricted groups
themselves and members of these groups will see an option to leave the group on
activity pages. Align whether the client shows the "Leave group" option with h's
behavior.

During this change it was noticed that the documentation in the code and test
descriptions did not match the actual handling of `allowLeavingGroups`. The
comments said that services had to explicitly set `allowLeavingGroups` to
prevent users leaving. However the code would treat `allowLeavingGroups` as false
if a) service configuration was present and b) the value of `allowLeavingGroups`
was falsey (including undefined). Changing this behavior may cause issues for
existing users of third party authorities, so this commit updates the
documentation and tests to accurately describe the current behavior.

Fixes https://github.com/hypothesis/client/issues/6637
      d14c255b
  5. 28 Oct, 2024 11 commits
  7. 23 Oct, 2024 1 commit
  9. 22 Oct, 2024 2 commits
  11. 21 Oct, 2024 5 commits
  13. 18 Oct, 2024 1 commit
  15. 16 Oct, 2024 1 commit
  17. 15 Oct, 2024 1 commit
    • Robert Knight's avatar
      Initialize route state in store before fetching groups · 25358a00
      Robert Knight authored 
      The behavior of `GroupsService.load` varies depending on whether the current
route is the sidebar or not. During sidebar startup, `GroupsService.load` was
called before `RouterService.sync`. As a result the route was `null` during the
initial call to `GroupsService._loadGroupsForUserAndDocument` and hence the
service did not execute the sidebar-specific code path to wait for the document
URI to become known at that point.

During the first `GroupsService._loadGroupsForUserAndDocument` call,
`_setupAutoReload` would set up a watcher that would react to changes in
`store.mainURI()`. This watcher would fire after the main guest frame connects.
Depending on when that happens, requests from the initial `GroupsService.load`
request could still be in-flight. If the second set of groups API calls
completed first, followed by the first set of groups API calls, then the final
set of loaded groups might reflect the _first_ call to `GroupsService.load`,
where the document URI was not used (because the route was unknown).

This commit fixes the issue by re-arranging the sidebar startup sequence to
initialize the router service before other services.

Fixes https://github.com/hypothesis/support/issues/79
      25358a00
  19. 14 Oct, 2024 10 commits