ml8 / slack-queue Goto Github PK

Requirements

No commands have tests right now, these tests need to be written

Steps to reproduce

Expected behavior

Block messages can't be displayed as notifications, so the main message should be text (maybe with a bloc attachment)

Actual behavior

Why

Users should be able to moderate/reorder the queue

Expected Behavior

Move(2, 3) should swap 2 and 3. Move (2, 8) should move 3-7 up a position.

Not included

Steps to reproduce

Call '/list' with an empty queue.

Expected behavior

A message that the queue has no one in it will be displayed.

Actual behavior

The http request returns an error status, resulting in the slash command failing.

Why

To expose telemetry.

For tutoring, for example, it is required to have a record of activity. This can be parsed from logs, but it would be better to have explicit hooks (e.g., PUT/POST requests). Imagining using this API for Sheets, for example.

Expected Behavior

Via flags or a config file, let users specify some hooks for various operations. When an operation occurs, that hook is notified. At the very least, support some sort of web hooks.

Steps to reproduce

• Create a queue with no administrator channel
• Recover state

Expected behavior

• Queue should have no admin channel

Actual behavior

The recovered queue looks for an admin channel, even though there is none.

I0128 22:43:18.337935       1 server.go:125] Creating server for channel C01HKC7KWHG with admin channel
...
E0128 22:43:36.296391       1 admin.go:128] Could not find admin channel. Retrying.
E0128 22:43:36.296598       1 list_command.go:71] Permission denied to user XXX

Why

A single queue per workspace is essentially a toy use.

Expected Behavior

Users can create a queue by adding the bot to an admin channel and creating a queue with an admin channel option + queue channel or name option. The queue would be per-channel or per-name. This would essentially be the same thing as ubots queue.

Details

This isn't a huge refactor. Requires an additional layer of abstraction at the main layer (which needs to be refactored anyway) to direct to a particular queue.

This would require a better persistence model and metadata per-queue.

Requirements

Code is sparsely commented, needs to better documentation

Why

Admins are currently the only one who knows that a user was dequeued. Users should get a notification that they've come up in the queue.

Expected Behavior

The user that was dequeued and the admin that dequeued them should get a notification in a shared conversation. A "you've been matched!" type message.

Not included

Requirements

All integration testing is at the manual level, research and add integration tests

Requirements

The project README should describe what scopes are needed, how to run this, etc.

Why

It would be good to know why/what for/etc an element/user is queued.

Expected Behavior

Include an optional reason in the enqueue command that is reflected in the UI.

Not included

List/filter by reason, etc. It should just be a blob of text/bytes.

Why

Admins should be able to remove users from the queue

Expected Behavior

Remove(user) or Remove(3) should remove the user/index from the queue

Not included

Steps to reproduce

List the queue - the user profile image is way too upscaled

Expected behavior

Image is displayed at a higher resolution

Actual behavior

Upscaled

Fix is simple, just change the icon size displayed in the list response.

Requirements

There is a lot of duplicate code and lack of tests have allowed inconsistent ways that dependencies can be injected. The service side should be refactored.

There should also be an arbitrary notion of queue element -> service element -> UI element (related #19)

Why

Admins should use the UI provided by the List command to moderate the queue, including UI for take/move/remove.

Expected Behavior

The list response should return a block-based UI that will send requests for additional operations, that are then executed by corresponding commands (this probably involves refactoring the Command interface?).

The UI should use tokens to ensure that operations are carried out as a transaction.

Not included

Why

Currently all operations are in-memory, meaning a crashed process kills the queue.

Expected Behavior

The process recovers the queue on recovery.

Not included

There is support for journaling to a file, all that needs to be done is flags and doing this on creation.

Why

Users should be able to take users from other places in the queue

Expected Behavior

An admin should be able to do Take(2) to take the second person in the queue, etc.

Not included

Why

Removing many elements from the queue is tedious.

Expected Behavior

Flow should be to list the queue, then to moderate from the single response. This requires updating the original list response from the remove action e.g.

Not included

Steps to reproduce

If the process crashes during a user lookup in Service.Dequeue, the taken user is dropped. Similarly, if the user lookup fails, the user gets moved to the end of the queue.

Expected behavior

User shouldn't be dropped, and queue shouldn't be modified.

Actual behavior