[Suggestion] Rules for the behaviour of stacks
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 1.4k
- Forks
- 354
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 43
Description
How to use GitHub
- Please use the 👍 reaction to show that you are affected by the same issue.
- Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
- Subscribe to receive notifications on status change and new comments.
Is your feature request related to a problem? Please describe.
In #534 options for stacks, including marking them as "Done" stacks, which could change the appearance of the due-date. This issue is a possible addition to #534, which could make it easier for the user to see and define "magic abilities". I have created a new issue, since it is not directly related to the initial idea of #534 and implementing one without the other is possible.
Should cards automatically get marked as "done" when moved to the "done" column?
it sounds good at first sight, but I think my answer is 'no' because I cannot think of a good way to convey to the user that a certain column has this magic ability, or how to set this magic ability for a certain column. So it would be intransparent for the user.
Suggestion for adding rules
Since it would be nice for the user/board owner to define these rules himself (e.g. if he want's to set done=false if the card is moved out of the done stack or he has his own tag to be added if a card is moved) this could be the solution to make it more transparent for the user:
- Add a options field to the stack (e.g. using the sidebar used for Cards), which opens that sidebar for the stack.
- In the sidebar there could be a way to define your own rules (see later)
- To make those special stacks more transparent for the user a icon (e.g. event / lighting bolt) to the stacks title.
- Maybe even add a tooltip to this icon showing either a text like "This stack has rules that change a card on entry/exit" or a textual representation of the rules defined
For the rule definition there are multiple ways to do that:
- Graphical way: A list of actions to execute on entry/exit of the card and a list of actions (e.g. add_tag, mark_done, mark_not_done), which can be dragged (or added via a add button) to the entry/exit list.
- Textual way: Maybe a simple, easy to understand textual representation would make sense. Subtasks are done as text, too, using the description of each card. This could be easier to implement and by adding a short help/info button/text and a easy syntax the user should be able to use this, especially because he doesn't have to change these rules often. (would be my personal preference)
Here is an example of how the textual description could look like
on_entry: add_tag(finished)
on_entry: mark_done
on_exit: mark_not_done
on_exit: remove_tag(finished)
on_exit: add_tag(reopened)
Maybe there could even be conditions (e.g. based on tags or if a card was marked as done (depending on how #534 is implemented)):
on_entry: add_tag(important) if not is_done and is_overdue
Other cases where this could be useful is: on_title_change, on_description_change, on_due_date_change
As mentioned before: the textual description could be shown in a tooltip for each stack, as it should be human readable enough.
Independant of which way to defne rules is used, some way of representing these rules / interpreting them would be needed. Maybe store the rules in the textual representation and interpreted when a card is moved between stacks
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files or tests are named. Start by reading related issue #534 and tracing how stacks and cards are configured and moved in the JavaScript application. Done would require an agreed rule model, visible stack configuration, and defined entry/exit behavior, but the proposal does not settle the syntax or scope.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- backend, frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 18/100