🇲🇾Malaysia @muaz91

+1 for RTBC patch #17

Hi,

If someone having trouble getting the recepient when sending message using ECA modeller, you can tested out the ECA modeller attach

To import can go to Import ECA page "/admin/config/workflow/eca/import" and Choose the tar.gz file

Hi, I'm getting the same problem. However, this only occur when using the contrib module Field_validation version 3.0.0-beta3. If you use the 8.x-1.1 all seems to be working as expected.

Hi @jurgenhaas, I have tried fresh Drupal installation 10.3.1 with standard setting, and only install ECA 1.1.7 with BPMN.io 1.1.4.

The problem still occured. can you help? please thank you

muaz91 → created an issue.

I've also sometimes getting duplicate users when user registering with google. Using patch from #8 and will get back tommorrow to see the result

I've created a custom module with this code:

<?php
use Drupal\Core\Access\AccessResult;

function CUSTOM_entity_field_access($operation, \Drupal\Core\Field\FieldDefinitionInterface $field_definition, \Drupal\Core\Session\AccountInterface $account, \Drupal\Core\Field\FieldItemListInterface $items = NULL) {
  if ($field_definition->getName() == 'access' && $operation == 'view') {
   return AccessResult::allowed();
  }
  return AccessResult::neutral();

hope this help.

Having the same problem. it seems the patch from MR!3 is working. Not sure about the comment above me.

+1 for rtbc

+1 for RTBC Thanks @chetan 11

muaz91 → created an issue.

@Anybody. ok done.

Hi,

I've reroll the patch from #12 so that it can be use with front : composer require 'drupal/front:9.1.x-dev@dev'

I have manually changes the code based on git 69 so that it can be use with the latest private_message ver 3.0.0. the patch is as attach if anywant wanted to test out

big thanks to @dinazaur, @abramm, and @sagesolutions!

Hello,

Not sure why, I cannot test out the patch, most file patch failed. I am using private message version 3.0.0 (composer require 'drupal/private_message:^3.0')

Not sure if its help, the log is as attach

It works! I've tested out with annonymous, and also with disabling bigpipe. both works.

Thank you @jurgenhaas

Good finding. Shouldn't we try and make it work in all cases?

It would be great! I can help test @jurgenhaas

set this to fixed. thanks @jurgenhaas

Hi,

It seems that the problem is occured when disabling the module bigpipe. I'm not sure why I've disabled it before. When enable the notification is shown as normal.

I am sorry for not clarifying enough for my comment. I have tested out on both logged in and out, and both does not show any notification when redirecting to another page.

For my use case is actually for authenticated users, and as stated, the redirecting is okay, but the message does not shown as expected. I've attach screenshot for the ECA model setup below

@jurgenhaas, I think both. I've test for anonymous still not have the notification message

I've also tried another kernal event "Start dispatching request" with the same conditions and actions, the url redirect is working, but the notification still does not shown

muaz91 → created an issue.

Great work @sagesolutions!

I have tested out the blocking system for private_message. I can say it works for me as expected.

When User A blocked User B:

1. User A can view the private message with User B, and cannot send any messages
2. User B can view the private message with User A, and can send message as usual
3. When User B does not know whether they are not blocked, as they still can message User A as usual
4. When User B message the thread, User A cannot see whats new in the thread
5. When User B message the thread, User A will not get new notifications, this include email too
6. If User A remove User B in private message block, User A can see latest messages from User B in the thread
7. If User A remove User B in private message block, there is no new notifications if User B send message before the unblocking

I can say this is RTBC, as a base for blocking system, it works.

muaz91 → created an issue.

I sorry I am not sure how to make a patch, for anyone wanting to fix:
edit this file src/UploadImageChangerHookImplementations.php

change this:
$new_mime = mime_content_type($derived_uri);
to this:
$new_mime = \Drupal::service('file.mime_type.guesser')->guess($derived_uri);

muaz91 → created an issue.

muaz91 → created an issue.

Test out the patch from #81. it help out the SameSite cookie problem for me. +1 for RTBC

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

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