Add possibility to archive project
Closed this issue · 6 comments
Archived projects shouldn't be present in the left menu bar. At the bottom of the project-selection menu should be an icon to display/collapse also archived projects.
Project should be archived by writing msg (archive :__cledara) to the #pm-reports channel. The command should be able to take more projects: e.g. (archive :__prj1 :__prj2) . Implement also the unarchive function with the same signature.
Make sure that the parsing mechanism can handle whitespaces (including newlines) in between the words.
As for the UI, I don't mind if the same effect ((un)archiving projects) is achieved via standard fronted, but I think that parsing messages from Slack is something we already do, so why not use it.
As for the UI, I don't mind if the same effect ((un)archiving projects) is achieved via standard fronted
UI is the client? So it should be possible to (un)archive projects from the browser?
This feels strange, because currently we can't change the DB from the client.
As for the UI, I don't mind if the same effect ((un)archiving projects) is achieved via standard fronted
UI is the client? So it should be possible to (un)archive projects from the browser?
This feels strange, because currently we can't change the DB from the client.
Yes, UI = client. Just to be sure, the point of these few sentences were that I suggest we don't do any (more) UI, so let's just stick with the slack messages. I think we are on the same page here.
Project should be archived by writing msg (archive :__cledara) to the #pm-reports channel.
Should the bot check if the message is from #pm-reports, or is it ok if the (un)archiving works from all the channels the bot is invited to?
Here are different proposals on how I could specify the syntax and semantics of this command.
I'd prefer the 2nd one, @tomaskulich which one would you go for?
EDIT: see my conclusion at the bottom.
proposal 1
syntax:
Any message is an archive command that starts with the word archive (or unarchive). Any tokens found in such message are considered arguments.
This means that the command can include arbitrary text, which is ignored.
Motivation: otherwise, if text is forbidden in the command, then such message would be considered a report, which is ambiguous.
semantics
The project is archived if we receive an archive command or if an archive command is produced by editing an existing message.
Motivation: if the user mistypes the command, then it will be a report. They should be able to fix this by editing the message, rather than deleting and writing a new one.
In this case it's important that we remove the edited report from the database. No other action is taken based on the previous value of the edited message. (i.e. we don't unarchive a project because the archive message is edited to something else, or deleted)
proposal 2
syntax:
I'd use the same as above, but we can also forbid non-whitespace characters not part of the command.
semantics:
Only new messages are considered when looking for commands, edits are not.
proposal 3
syntax
/archive tag_1 [tag_n], so it would be a slack slash command
semantics
Obvious. It's not possible to mix up reports and archive commands, or to edit previously issued commands.
But unlike messages, bots receive slash commands from any channel. So it's has less "by-definition" security, but it's possible to check manually if the command came from a channel the bot is in (except #general, where everyone is member)
Another aspect of the question is the catchUpMessages happening when the bot comes back online, after some time offline.
If we want this functionality to work with archiving too, then
- we can rule out slash command as a possibility
- we have to reorder the messages to catch up by time (of sending or last edit), because right now they are processed channel by channel.
PR #39 contains an implementation of proposal 1 from above.
I've decided for this over prop. 2, because when a message is edited to an archive command, I would have to explicitly ignore it, or let it be registered as a report. Now I recognize it as a command.
There are 2 inconsistencies with this solution, but these are probably acceptable:
- you can't undo a command by deleting (or editing) the message
- deletes and edits are not caught up with at all
If it turns out that catching up commands is not an important feature, I would still consider proposal 3 a better solution.