Flood control for actions

Created on 24 July 2023, over 1 year ago
Updated 22 June 2024, 6 months ago

Problem/Motivation

Some actions are carried out within entity references or crud operations performed on the site.
For example, an email is sent when a node is liked(votingapi) or commented on.
No problem so far...

However ,
For example, a user like a node then cancelled it and liked it again after a few seconds. Two email notifications will be sent during this process... Pressing three times means three emails....Or imagine that the user is malicious and presses the like button dozens of times in seconds. Of course, this may not always be malicious... Imagine that periodic comments about a flowing topic are written, deleted and rewritten..Either maliciously or by accident, other user(author) will receive notifications about the same node (topic) every time.
This process will not only force the site, but also disturb other users.

I'm wondering if there is a way to limit sending notifications or emails to once a day (or another limitation) in the same process.

Or crud operations can also be restricted. But there is a problem with this point of view. When this crud limit is reached, action will have already occurred and notifications will have been sent.
Depending on the scenario, both perspectives may be more productive.

Waiting for advice. Thanks

💬 Support request
Status

Closed: outdated

Version

1.1

Component

Code

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @erdm
  • 🇩🇪Germany jurgenhaas Gottmadingen

    That's an interesting requirement, and from my POV this is something that needs to be solved with logic that is not ECA related - it requires a solution that would be applied in each context/toolset that would be used to implement this.

    What's required is some stateful system. The workflow would have to define a ruleset, e.g. like described in the above issue, where the state is being saved per user, and notifications will then be sent by another model which reads the state and then takes some action following the previously defined rules.

    As for ECA, it is possible to write and read state values. Or you can add a field to the user entity, that is otherwise invisible (from the form and the profile view) and keeps the state information which helps you to decide, whether a notification should be sent or not.

  • Hi Jurgen,
    I know it's not an ECA related problem.
    Since I use ECA for notifications in the above scenario, I wanted to get advice by thinking if I can solve it with ECA again.

    I will listen to your advice. By the way, I would be very happy if you could evaluate this scenario at tube.tchncs/ecaguide

    Thanks

  • 🇩🇪Germany jurgenhaas Gottmadingen

    Since I use ECA for notifications in the above scenario, I wanted to get advice by thinking if I can solve it with ECA again.

    Sure, like I commented before, you need to store the state information somewhere, either in Drupal's state system or with the user entity. And then you can make your decision inside ECA based on the stored state information and your specific conditions. Not sure what else I could advise. Going deeper would have to go into data modelling and so on, which is a bit too much to ask for as free support.

  • Status changed to Postponed: needs info over 1 year ago
  • 🇩🇪Germany jurgenhaas Gottmadingen
  • Status changed to Closed: outdated 9 months ago
  • 🇩🇪Germany jurgenhaas Gottmadingen
Production build 0.71.5 2024