You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
New endpoints: info, polling, fetching, permissions, pinning
Implements a bunch of new sogs endpoints, mostly as described by the api
spec (with some changes applied to the spec, where needed):
- `/rooms` -- returns list of readable rooms, including various room
metadata plus derived permission of the user in the rooms
- `/room/<token>` -- same as above, but for a single room
- `/room/<token>/pollInfo/<id>` -- polls a room for any metadata updates
applied since `<id>`. If the room's current metadata tracker
(`info_updates`) is unchanged from `<id>` then this returns a light
poll response with just active_users and current user permissions in
the room; otherwise it includes that plus a `details` key containing
the full room metadata (as would be returned by `/room/<token>`).
Message fetching endpoints:
- `/room/<token>/message/1234` retrieves a single message with the given
id.
- `/room/<token>/messages/recent` retrieves the most recent 100 messages
in a room.
- `/room/<token>/messages/before/123` retrieves the most recent 100
message events (i.e. post, edits, deletions) immediately preceding the
*sequence value* 123. (This is not a message id, but rather the
messages `seqno` value).
- `/room/<token>/messages/since/456` retrieves the next 100 message
events following `seqno=456`.
- all of the above except for the single message endpoint support a
`?limit=42` parameter that allows values up to 256.
Message pinning (these all require *admin* privileges, not just
moderator permissions):
- POST `/room/<token>/pin/123` pins the message with id=123 to this
room. (Note that this adds a pinned; if there are other pinned
messages you end up with multiple pinned messages).
- POST `/room/<token>/unpin/123` does what you'd expect.
- POST `/room/<token>/unpin/all` does what you'd expect.
- `/room/<token>/pollInfo/<id>` and `/room/<token>/messages/since/456`
together replace legacy SOGS compact_poll *and* the need for periodic
room info fetching.
Ideally you'd poll everything in once by throwing these into a
sequence request such as:
[{'method': 'GET', 'path': '/room/room1/pollInfo/123'},
{'method': 'GET', 'path': '/room/room2/pollInfo/456'},
{'method': 'GET', 'path': '/room/room1/messages/since/789'},
{'method': 'GET', 'path': '/room/room2/messages/since/1011'}]
The first two give you room information such as the number of active
users and your current permissions, and when room details change,
the full room metadata (name, description, pinned_messages, image,
moderators list, etc.)
The second two give you new post updates (i.e. new posts, edits,
deletions) for the two rooms.
(It may sometimes be necessary to submit extra fetch requests if the
messages-since endpoints give back a full set of 100 message
updates).
Other notes:
- both the polling and full version of room details include the current
permission keys,
`read`/`write`/`upload`/`moderator`/`admin`/`global_moderator`/`global_admin`,
which clients can use to update the UI as appropriate.
- Room "updates" and post "updated" are renamed to "message_sequence"
and "seqno", respectively, to better describe what they are. That is,
these define the sequence of updates that a client needs: a new post
counts as an update, but so does an edit to and existing post and a
deletion. The old name was rather confusing since there is also an
`info_updates` on rooms which tracks changes to room details like
name/image/etc.
- Simplified the active_users to report a single value plus the cutoff
for that value (which is sogs-admin configurable). Previously the API
specified that it would return a default plus several different
values, but that seems needlessly complex. The cutoff, however, might
be useful for an advanced page to know the time frame beyond which
users are no longer considered "active".
- Added notes to file expiry that the short expiry until association
with a post isn't implemented yet.
- Fix the user_permissions view not returning true for read/write/upload
for moderator permissions in rooms if the permissions were not
specifically applied to the moderator. (Moderators/admins always have
those permissions even if the defaults are false).
- Split up the moderators/admins list in room info so that regular users
can distinguish between room moderators and admins, and so that
mods/admins can distinguish between hidden mods/admins.
- Add extensive unit tests for everything above
0 commit comments