Just one remark here, @Ayush8923 : The configuration should be stored as its own EntityType (maybe "NotificationConfig:<user_uuid>" or whatever name you suggest as more fitting).
We recently have moved away from combining any different data into one entity for various reasons and not every customized system even has a "User" entity type now.

Just one remark here, @Ayush8923 : The configuration should be stored as its own EntityType (maybe "NotificationConfig:<user_uuid>" or whatever name you suggest as more fitting). We recently have moved away from combining any different data into one entity for various reasons and not every customized system even has a "User" entity type now.

Thanks for this remark @sleidig. I have updated the draft database schema in the issue description. Please take a look once and let me know if there are any changes needed.

as per group discussion:

{
    "_id": "NotificationConfig:<userId (Keycloak ID)>",
    "_rev": ...,
    "created": ...,
    "updated": ...,
    "channels": { "push": true, "email": false }, 
    "notificationTypes": [
        {
            "notificationType": "entity-update", // in the future also e.g. "new_app_release"
            "enabled": true,
            "channels": { "push": true, "email": false }, 
            "entityType": "User",
            "conditions" // as <DataFilter/MongoQuery>, see https://www.mongodb.com/docs/manual/reference/operator/query/
        },
        {
            "entityType": "Task",
            "conditions": {
                "authors": { "$in": "<userId>" },
            }
        }
    ]
}

@sleidig @tomwwinter @george-neha, In the notification setting page, I have created an initial UI(attached screenshot below) for the notification condition field. In this UI, the user first selects an entity type and then the user adds the corresponding fields (e.g., subject, name, etc.) with which the user wants to perform the comparison. Then the user selects an operator (e.g., Equals, Greater than, etc.) and specifies a value for the comparison in the notification condition.

Please check this initial UI and share your inputs or suggestions. Also, please let me know if I have missed anything.

We should support multiple conditions (so probably similar to the "add new notification rule" button, we can have a "add condition" button to add another block of this). Accordingly, I would move the condition fields to a second row in the box and maybe make that expandable/collapsible for easier overview of all rules.

A general thought coming to my mind: These conditions are actually similar (or probably the same?) as the filters to filter entries in the EntityList views. Can we reuse those UI components to filter data for the notification conditions instead of introducing a new model?

We should support multiple conditions (so probably similar to the "add new notification rule" button, we can have a "add condition" button to add another block of this). Accordingly, I would move the condition fields to a second row in the box and maybe make that expandable/collapsible for easier overview of all rules.

A general thought coming to my mind: These conditions are actually similar (or probably the same?) as the filters to filter entries in the EntityList views. Can we reuse those UI components to filter data for the notification conditions instead of introducing a new model?

Yes, I agree with the idea of supporting multiple conditions. Implementing an Add Condition button (maybe we can add the plus icon) for each rule will make the feature more flexible.

Yes, Instead of creating a new component, we can use the existing EntityList filter components for notification conditions. I’ll check the current filter implementation to evaluate how it can be adapted or extended for this use case.