Customize completed/deleted movement targets

[stranger-danger-zamu]

On a slightly different track, being able to customize the movement between the stack and the suffixed stacks (eg. ${stack}_completed, ${stack}_deleted) would be pretty awesome.

For example, the watch-later stack items could be moved into watch-later_${rating} (eg. watch-later_thumbsup, watch-later_3, and so on) where the end stack is the rating. These could be anything, so it really empowers the user to use this for anything. You could do a pseudo Kanban system where you move the task through a sequence of stacks without touching the original message. A nice-to-have would be the ability to define the valid targets preemptively. So if its target is not in the predefined set of targets (eg. {1,2,3,4,5}, {thumbsup,thumbsdown}), the command does nothing and protects the user from themselves.

[booniepepper]

This is another great idea!

I definitely need to think on the "lifecycle" idea in a more general way. I really like the idea of configurable targets

The idea of just suffixing _completed or _deleted that I've gone with is very unsophisticated. It works for what I need Sigi to do for me, but also... it could lead to some weird nesting like ${stack}_completed_deleted_completed_completed}. I think that could compound in a possibly sad way if I leave it the way I've got it.

Maybe there's an idea here also of making the "completed/deleted" stacks not be just named stacks, but be something a little more special. A simpler idea could just be to validate the stack name is not already suffixed with a state name. I could also use some different character and say it's a reserved character in stack names (e.g. a colon)

These kind of changes would potentially break people, though.

So maybe the idea here is twofold:

1. Allow configuration for arbitrary states

2. Decide how to handle item states (either introduce some safety or decide to defer that to a user)

[stranger-danger-zamu]

On an unrelated note, creating another term for the set of related stacks that transitions occur within would be pretty helpful. Calling it a stack seems disingenuous since it is a set of stacks. Possibly call it a database or repository would work better.

---

Validating arbitrary user-defined states

You can do a pretty simple regex pattern to match against a list of suffixes and store a list of valid suffixes for each database/repository/set of stacks.

Given a user has a movie_rating repository and they want to only support yay or nay as ratings, then matching the target stack against ^movie_rating_(?:yay|nay)$ would work. Creating the pattern would be as simple as ^${stack_name}_(?:${suffix_pattern})$ where suffix_pattern would be joining the list of suffixes with a vertical bar.

Just ensuring that suffixes are alphanumeric (and possibly additional set of supported characters) would then ensure that no shenanigans could occur with regex escaping.

IMO, the best implementation would be a set of valid targets for each stack within a repository since then you would have a directed graph validating all transitions. Though, I'm not sure a lot of people would want to configure that.