Flexible notifications for cards, boards and other entities based on an event driven rule engine with user GUI

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.
The current options for notifying users do not appear to be backed by a fundamental functional concept.

• We have notification settings in the user settings
• We have notification settings when you click on the three dots on a board (for a specific board)
• We have notifications that always come regardless of the notification settings, e.g., when a user is assigned a card.

In #3547 two people describe which problems the current notification behaviour causes on their side. Another 4 people gave an upvote indicating they also have these problems. It looks a little as if everyone has “tinkered” with it here and there.

With this feature request, I would like to share my thoughts and offer an approach to how I would solve the specific requirements for notifications.

However, my proposal does not represent a comprehensive technical concept (see also section “Alternatives”).

I would like to put my ideas up for discussion. I would be happy if we could distinguish between three points:

• Collecting use cases for notifications and categorizing them into “standard use case” or “special use case”
• Feedback on the concept I have proposed for special use cases
• Development of a general notification concept (Where are notifications set (Deck app or Nextcloud settings)? Are they listed centrally? Should there be a subscribe function in addition to the assignment function? For cards only? Also for labels?)

Describe the solution you'd like
I think the following notification functionalities would be useful:

• Notification on all events regarding a card you're assigned to. Also suggested in #5792 and #5274
• Subscribing to cards: Notification on all events regarding a certain card.
• Subscribing to boards: Notification on events, that affects a certain board.
  • Board deletion (was suggested in #5650)
  • A card was created on a board
  • A card was moved on a board
  • A card was deleted
  • A card was moved away
• Subscribing to certain labels could also be useful.

In my case a notification about moving cards events from a certain source board to a certain target board is needed. But this is so specific that I think about a rule engine with which you can target all the notification features mentioned above:

Rule engine concept

Let's assume we have event emitter in our application for every CRUD endpoint. This event emitter emits an event with a standarized structure payload if the CRUD endpoint is being called. It could be like this, I'm just fantasizing a little:

{
  "timestamp": "2007-08-31T16:47+00:00",
  "type": "<event type>",
  "target": {
    "<target type>": {
      "new": {}, // new object like a postgres trigger function
      "old": {} // old object like a postgres trigger function
    },
  },
  "source": {
    "actionType": "USER_ACTION || APP_ACTION (app password used)",
    "user": {
      "id": "",
      "firstName": "",
      "lastName": ""
    }
  },
  "actionParameters": {} // <type-individual dictionary>
}

So we have the emitter side now.

On the other side we need a rule engine with a user interface. Each user can set up his own rules. Example:

On event `<event type>` with following conditions (optional)
 - `<event parameter>.subKey` is `<expected value>`
 - `AND` `<event parameter>.someKey` like `%<expected part of value>%`
 - `AND` `<event parameter>.againAnotherKey` contains `<expected part of value>`
 - `AND` `<array>` contains a value matching `<key>` to be `<value>`
send a notification via `<channel>` with subject `<parameztized subject>` containing the following parameters:
 - `<target>.someKey`
 - `<source>.someOtherKey`

For this the rule engine needs to reveice/consume the events emitted by the endpoints.

The parametrized subject would also solve #7304 as you can now have user defined variables in the subject.

Examples:

For #5650:

Event:

{
  "timestamp": "2007-08-31T16:47+00:00",
  "type": "DELETE_BOARD",
  "target": {
    "board": {
      "new": null,
      "old": {
        "id": 42,
        "name": "MyBoard"
      }
    }
  },
  "source": {
    "actionType": "USER_ACTION",
    "user": {
      "id": "1",
      "firstName": "Jon",
      "lastName": "Doe"
    }
  },
  "actionParameters": {}
}

Rule:

On event `DELETE_BOARD` with following conditions
 - `target.board.old.name` is `MyBoard`
 - `OR` `target.board.old.id` is `42`
send a notification via `EMAIL` with subject "Board `target.board.old.name` was deleted!!!1" containing the following parameters:
 - `target.board.old.name`
 - `source.user.firstName`
 - `source.user.lastName`

For subscribing on labels:

Event:

{
  "timestamp": "2007-08-31T16:47+00:00",
  "type": "ADD_LABEL",
  "target": {
    "card": {
      "new": {
        "id": "1",
        "title": "Foo",
        "description": "Lorem ipsum",
        "assignees": [
          {
            "id": "1",
            "firstName": "Jon",
            "lastName": "Doe"
          }
        ],
        "labels": [
          {
            "id": "2",
            "name": "AI-QS"
          }
	]
      },
      "old": {
        "id": "1",
        "title": "Foo",
        "description": "Lorem ipsum"
      }
    }
  },
  "source": {
    "actionType": "APP_ACTION",
    "user": {
      "id": "99",
      "firstName": "Jon",
      "lastName": "Bot"
    }
  },
  "actionParameters": {
    "label": {
      "id": "2",
      "name": "AI-QS"
    }
  }
}

Rule:

On event `ADD_LABEL` with following conditions
 - `actionParameters.label.name` is `AI-QS`
 - `AND` `source.user.id` is `99`
send a notification via `EMAIL` with subject "Jon Bot made a quality check on card `target.card.new.name`" containing the following parameters:
 - `target.card.new.id`
 - `target.card.new.labels`

For being notified on new comments for all assigned cards:

Event:

{
  "timestamp": "2007-08-31T16:47+00:00",
  "type": "ADD_COMMENT",
  "target": {
    "card": {
      "new": {
        "id": "1",
        "title": "Foo",
        "description": "Lorem ipsum",
        "assignees": [
          {
            "id": "1",
            "firstName": "Jon",
            "lastName": "Doe"
          }
        ]
      },
      "old": {
        "id": "1",
        "title": "Foo",
        "description": "Lorem ipsum"
      }
    }
  },
  "source": {
    "actionType": "USER_ACTION",
    "user": {
      "id": "100",
      "firstName": "Johnny",
      "lastName": "Depp"
    }
  },
  "actionParameters": {
    "comment": {
      "content": "I'm an old-fashioned guy!"
    }
  }
}

Rule for user Jon Doe (id 1):

On event `ADD_COMMENT` with following conditions
 - `target.card.new.assignees` contains a value matching `id` to be `1`
send a notification via `EMAIL` with subject "New comment on assigned card `target.card.new.name`" containing the following parameters:
 - `target.card.new.id`
 - `targt.card.new.comments`

Far future: Describing email templates in which the notification is filled in so that the parameters are not appended raw in the email body.
Far future: This rule engine could later be upgraded and used to take several actions like prohibiting a user to remove certain labels from a card for example. The propoesed data structure of the event is able to fit those requirements.

Describe alternatives you've considered
I know it is not very convinient to set up a rule for every action that can be taken on a card to being notified if you are assigned to a task. So the notifications suggested in #5792 and #5274 should be also implemented independent from this rule engine porposal to have an easy way to receive notifications for all events that effects a card you're assigned to.

Additional context
At the moment i really don't know how to add more context here :)

The issue names no implementation files, tests, or concrete entry points. Begin by mapping the existing user and board notification settings and the CRUD endpoints that would emit events, then review the proposal with maintainers to define a narrower scope. Done requires an agreed notification model and implementation plan before coding can begin.