Add more plugins

Should I just get started on the suggested solution in #9 or is there any feedback that would tell otherwise?

sorry for the late reply @jurgenhaas

Events

Is there a use case where those 2 events would be used without providing a flag name? In other words, the same event, but more generic?

I think not, the event needs to be trigger with a flag name, specifically flag_id

There is potential confusion because there are already other events, that would provide the same functinality: when a flag entity gets created (a.k.a. an entity got flagged) or deleted (a.k.a. an entity got unflagged). So, instead of creating new events, we could use those that are already there and provide access to the respective flagged or undflagged entity by adding that to the token stack in addition to the flag entity. Also, the flag name could be asserted in a condition.

For me personally, I know that the event insert an entity and delete an entity is the same as flagged and unflagged. However, for the perspective of the maybe some user whom use the flag, they might confuse with the term. Maybe atleast need to describe it at the front page of the eca_flags? or in the eca documentation, so at least others know about it? also need to remove the flag/unflag event in the eca_flag module to avoid more confusion.

Conditions

[Entity] has flagging count: this makes sense, but I don't think we need the second field "Entity type" because we're checking an explicit entity which has its type and bundle. Right?
[Entity] is flagged: same as above, makes sense but we don't need a field for the entity ID because we are checking for a given entity. OK?

for the conditions, I have use the [entity] is flagged, the exact example is "node is flagged", the use case for me is when a person A is flagging a specific node with node type = article, entity_id is nid = 3, user whom behalf to check is uid = 1, then an action will trigger. Maybe the entity type is not that required after all, but the entity_id is important as it can specify what is the specific entity that we will check.

In addition to achieve what I proposed for the events above, we should add a condition to check the flag name for the flag entity that got created or deleted by the preceeding event.

agreed

Actions

The first 2 actions are not required, as they already exist in the Flag module, don't they?

I Think so, I saw it in the actions, but not test it out yet

Trim a Flag: what's that? I'm not sure what's meant by trimming a flag.

Sorry, I too does not know about it. Maybe for limiting the number of flags? this is just a speculation based on this issue que https://www.drupal.org/project/flag/issues/1094048 →

Fetch users who have flagged [Entity]: couldn't that be done with views?
Fetch entities flagged by user: same as above, I would have thought that views should be able to do that, no?
Fetch entity flag by count: what does that do?
Fetch overall flag by count: same question, I'm not sure what this is doing?
Fetch user flag by count: and also here, please clarify the purpose of this.

This too, I also does not know as I am not use the actions..

Apologize, this is very much info that I can give and help out.. Thank you very much for your work @jurgenhaas

Thanks a lot @muaz91 for your extra feedback, this is great help for me and there's no reason to apologize. You're doing so much above and beyond the "normal user", it's really much appreciated.

I think, I'm able to get this implemented with your comments from above and once we'll have that available to play with, it may become easier for us and hopefully other, to identify further gaps. Those can then be filled in subsequent steps.

And you're absolutely right, we need to write documentation so that people understand how to use all this. Ideally, a nice overview on the project page, with all the details in the ECA Guide then.

Although the flag module is not ready yet - as stated on its project page - I guess we have a pretty good integration by now in our dev release of eca_flag.

Foremost, you need to apply the patch from https://www.drupal.org/project/flag/issues/2500091#comment-14848519 🐛 Re-implement hook_tokens() Needs work on the flag module because otherwise you won't have any tokens, but they are essential for the functionality.

Then, here is how it works:

• Events
  • I kept both approaches in. You can either react on Insert flagging entity or Flag events. Both will operate similarly. The same for either Delete flagging entity or Unflag events.
  • If either of those events gets triggered, ECA puts several things onto the token stack:
    • flag the flag entity
    • flagging the flagging entity
    • entity the flagged or unflagged entity

    Note: if a flagging gets added or if the unflagging happens on exactly on entity, then you get those items on the token stack. However, unflagging can be triggered for many entities at once, then you get a list on the token system under the name flaggings where each item in the list contains the tokens listed above

• Conditions
  • There is 1 new condition from eca_flag which asserts if a given entity is flagged or not
  • All other conditions can be achieved with the Compare two scalar values condition by using tokens from the flag entities
• Actions
  • There is one new action to get one or many flagging entities for a given entity and stored as an entity or a list of entities onto the token stack

I've played around with this and it looks as if everything described above can be achieved with these building blocks.

Please review if you can and then we could publish a first beta release. Adding more plugins later is still possible, but for now, it feels as if this is now done.

Test out the patch. I mark this as RTBC.. Thank you @jurgenhaas

Thanks a lot @muaz91 for reviewing this and all your input to the effort. We can now publish a first beta release, which is great news.

Automatically closed - issue fixed for 2 weeks with no activity.