🇩🇪Germany @jurgenhaas

Maybe some day, but I can't do that soon. All required information is provided above, so maybe someone will be able to build such a model.

The patch doesn't properly apply any longer, so I'm creating an MR for the 3.1 branch.

As I mentioned in #2 you want to load that entity by properties. So you have to select that type. In the Property values field you will then have to define your property in yaml syntax on how to find a previous node of the current user. Probably something like:

uid: "[user:uid]"
type: "profile"

Tip: if you could provide screenshots in English, then more people will have a chance in reading them. You can also embed the screenshots so that they're visible without having to open them separately. Just a bit of best practice which makes free support a bit more efficient.

Yes, that looks about right.

That sounds like a good idea to add support for hook_node_grants and hook_node_access_records, maybe also for hook_node_grants_alter and hook_node_access_records_alter.

It's just unfortunate, that this is only available for nodes, and not for entities in general.

However, I'd say this functionality belongs to the eca_access sub-module.

That sounds like you're looking for a block condition, and that's available with this module → .

How to do this, because contact forms do not seem to be supported by this module.

There is nothing that needs specific support to do what you're asking for. Just use the Controller found to handle request event to get started, then check if the current request is on the contact form, and then output a message with the available action plugins.

Great suggestions, I think some examples are already available from https://ecaguide.org/library but we certainly love to get contributions to add even more useful samples to the ECA Guide.

That's nice. Have you also seen the ECA Feature Demo sample? That does some magic stuff as well. Altogether, replacing the login destinations module is certainly possible with ECA and I know a few who already do that.

You could start with the Controller found to handle request event, check for the path if the user is trying to create a profile. Then you can try and load a profile entity with the Entity: load action by load it by property with the author ID being the current user.

If that action can't find any such entity, then the ECA model finishes automatically. If it does, however, that means that such a profile already exists and you can continue by redirecting to a different page and output a message.

There are people already working on this, I've seen this in action a couple of weeks ago and was blown away. You could ping @Jasper Lammens in the #eca channel on Drupal Slack, as he's the developer of that in a separate module, but I don't know if that's already available as an installable release.

I'm not deep into twig, so this is certainly a task for someone else.

@joseph.olstad tests are almost green. There are just 2 phpunit tests that I don't know how to fix. There is 1 about a missing core service, that's confusing. And another 1 is about regex and I don't think we've changed anything there and this must have failed already before.

Could you probably have a look into that? Everything else is resolved.

Yes, I've been in that frustrating situation before as well. Adding a CTA element (link or button) to open the consent widget inline with the AI or video overlay, seemed to be the most straight forward approach to help such users getting to their goal without having to navigate around.

Thinking about it a bit more, I could also imagine that an extra checkbox in the existing overlay widget for AI or remote videos, which asks for the permission to remember the decision, wouldn't do the same thing without having to open yet another widget. As that consent it perceived as a technically required one already, this should not impose any legal objections.

Thanks for your suggestion @mxr576, I've also followed the discussion over at 🌱 [policy] Treat username enumerations as security bugs that require Security Advisories Active about this topic.

What I'm wondering:

• Isn't it important to e.g. disclose the author name of e.g. blog posts? I see lot's of cases where the missing author name on blog posts is an issue when someone else wants to give credit when quoting them.
• Same thing may apply to many other scenarios, where attribution may be relevant and the username not being perceived as PII.
• Where would the username of a non-author being ever exposed to non-admins?

I'm all up for the idea, I just want to understand the implications.

And if we move on with this, as the user_privacy_cms recipe is fairly simple, would you mind if we installed and configured the 2 extra modules directly from one of the existing recipes rather than adding yet 2 more dependencies?

@mxr576 thanks for the link to the other issue. I'll also link ✨ Add User Privacy CMS recipe to Basic Privacy recipe Active as that may become part of this advanced recipe.

Thanks for your feedback. Regarding the classic modeller, there is not much maintenance going into it any longer. But there is some good news for you: the bpmn_io modeller can open those models for you, and it will automatically convert them for you. So, the migration path should be seamless.

Here is a link to the hint what needs to be updated: https://github.com/crowdsecurity/php-remediation-engine/issues/33#issuec...

Those enhancements look good to me, just merged them. Thank you all for your contributions.

jurgenhaas → made their first commit to this issue’s fork.

Yes, it works as expected. Ad webform 6.3 has no stable release yet, maybe your project doesn't allow beta releases?

You can easily find out with compose why-not drupal/webform 6.3. Or you can require drupal/webform first and then require drupal/eca_webform afterwards. Maybe the first step already fails, then we're talking about a webform issue, not about a eca_webform issue.

Just realized, that eca_webform 2.0.1 already accepts webform 6.3 which is compatible with Drupal 11. So, you need to find out why your installation is not using webform 6.3, this module is ready for it and there's nothing we can change here.

Thanks for reporting, will fix that today.

Merged and backported. Thanks @freelock

What's required to alter the access on views results is an event or a hook that's being dispatched by the views module so that other modules can alter the results. If there isn't an API for that, ECA won't be able to get involved. I'm not sure from top of my head if anything like that already exists? How would you alter the access on views results when you would do that with custom code in PHP?

Thank you @spiderman for your contribution. A couple of things, though:

• This is for version 1.1 which is pretty old and not supported much longer. In 2.x this code doesn't exist anymore and therefore can't be applied.
• Contributions with patches won't move far, only issue forks and MRs should be used as those will run tests and also make collaboration so much smoother for everyone.
• And last but not least, a small tip on how you could debug is a more focused way: leave the settings at the error level for logs, and within your model, use the Set ECA log level action to turn on debugging at a specific place in your model to just get debug messages for that particular area.

Do you know the webprofiler module? That comes with some pretty helpful ECA debugging support as well.

That said, I guess that this feature request will probably not be landing in ECA.

Merged and backported to 2.0.x

Thank you all for testing and feedback, will publish new releases soon.

Oh great, now I can reproduce the problem. Thank you so much @gge

I've now taken a different approach in the MR and it seems to be fixed here. Please give it another try and set to RTBC if successful.

That's exactly right. We've discussed this yesterday as well and plan to provide the consent manager link nearby as well in such a scenario, so that this gets more obvious.

Yes, that makes perfect sense. But what's the problem then? Each event provides the entity that triggered the event under the token named entity. If you want to have it under a different name, you can user the Token: set value action to that different flows will provide the same token names.

You could e.g. start with the Controller found to handle request event and if it's a request to the path that wants to delete an entity, you can check the date and time, do all your checks, and if deleting is not allowed, you can do a redirect to a page that explains, why deleting is not possible right now.

@gge thanks for the instructions in #14. I wonder if there isn't a way to demonstrate the problem with just core and ECA? Modules like entity browser and IEF are so complex in themselves, that we should first try and reproduce this with plain Drupal.

jurgenhaas → made their first commit to this issue’s fork.

jurgenhaas → created an issue.

Test are green, merged.

This looks great, I've only cleaned up the code in 2 areas:

• Removed named arguments as we're not using them elsewhere either.
• Merged the 2 traits into the action plugin class, as those traits are not re-used elsewhere and are so small, that having them in separate files feels more overhead than benefit.

Thanks a lot @glottus for this contribution and congrats, your first MR went really well.

So, back to square 1: who can provide us with a step by step guide on how to reproduce this issue on a fresh Drupal 11 site?

Is this ready for another review? Status still says "Needs work".

Ping

Ping

Ping

Well, all entity properties are available as tokens, e.g. [node:title] and all the others. You can find all the available tokens with their syntax in the token browser, when you have the token contrib module enabled. And you can find comprehensive documentation about tokens at https://ecaguide.org/eca/concepts/tokens/

I can't reproduce this problem. I've created a model which does something similar and works as expected. I would assume that your token [rebuild_entity:entity:field_gr_profiles_er] is wrong, that's probably just [rebuild_entity:field_gr_profiles_er]. But I would even use the form build entity action, why not just load the referenced parent from the comment entity?

In ECA 2.0, the initialisation with neutral has already been built in as part of 📌 Enable event plugins to determine appliance Fixed . It's now contained in \Drupal\eca_access\Plugin\ECA\Event\AccessEvent::appliesForWildcard. The problem with that is in fact, if multiple ECA events are subscribing to the same Drupal event, then each of them initializes the access result again.

But the proposed MR resolves that issue correctly. Thanks @freelock for that suggestion. I've just left a couple of comments that are simple to apply.

Just playing devil's advocate: why is it helpful for a non-technical user to know about backend and frontend? Isn't it a huge benefit that they don't have to bother about that?

I've created an MR, please give that a try and let us know if that fixes your issues.

Thanks @abx for testing and your feedback. I'm closing this issue in favour of the other one, where we continue to fixing that bug.

This sounds a bit like mixing things up that don't relate to each other.

Have you read about the scope of tokens? You can find that here: https://ecaguide.org/eca/concepts/tokens/#scope-of-tokens

So, one event that's entity related, defines a token called entity. And that can never get in conflict with another event defining a token with the same name because tokens never get exposed between events.

Setting the access to an entity with the Set access result action can only be done in the context of an access event. Drupal wouldn't even bother about that otherwise. So, Drupal dispatches the access event for each entity that's being touched and for each of them you can respond by setting the access you want.

If the access result is depending on some other context, e.g. the access to a totally different entity, then you can either use a condition that determines if the user has access to that other token before setting your response, or you could store some context somewhere (e.g. temporary user state), and make your decision dependent upon those stored values.

Here is an example video with a list that comes from a view: https://tube.tchncs.de/w/jnzoru2XFHgpoToQB5P6AT

Here is another one: https://tube.tchncs.de/w/8dZuXYZHmuDTutddrTZUfE

Sure, adding more videos is what we always want to do if we find the resources to do so.

Is the code in the MR working?

jurgenhaas → made their first commit to this issue’s fork.

The ajax response actions only make sense when ECA responds to an ajax request. In other contexts, those actions don't make sense.

Interesting, I'm asking myself why it actually matters to recognize the difference between the admin and the frontend theme. Sure, it has lots of technical implications, but how is this important to the end-user?

jurgenhaas → created an issue.

jurgenhaas → created an issue.

jurgenhaas → created an issue.

jurgenhaas → created an issue.

jurgenhaas → created an issue.

jurgenhaas → created an issue.

jurgenhaas → created an issue.

jurgenhaas → created an issue.

jurgenhaas → created an issue.

jurgenhaas → created an issue.

jurgenhaas → created an issue.

RTBC+1, this would unlock a test blocker for other modules on Drupal 11 who depend on this.

jurgenhaas → created an issue.

The drush command would be drush config:set gin.settings enable_darkmode auto, but I'm not sure if drush commands are relevant for the target audience of Drupal CMS. Configuring this through the UI would probably be the recommended way.

jurgenhaas → created an issue.

jurgenhaas → created an issue.

jurgenhaas → created an issue.

I wouldn't enforce dark mode on everyone. If anything, setting the auto mode which uses the user's system settings is more appropriate.

jurgenhaas → created an issue.

jurgenhaas → created an issue.

So, this is likely a duplicate of the related issue. Therefore, can you try the fix I suggested there yesterday?

How does this module work, does it connect to a this party or is all local? Asking for privacy compliance.

@sundancenaturalist the best way to do things like this, is to develop against the latest release, 2.1.x in this case. Once finalized, you can then back port to previous release and, if necessary, be selective if some stuff wouldn't be supported there.

In a case where you would want to propose an enhancement without waiting for the latest release to accept the change before back porting, you would have to create a second branch in the fork and create another MR from there. So, you would then have one MR from 1.0.x in the fork to 1.0.x in the project repo, and another one from 2.1.x in the fork to 2.1.x in the project repo. But then, both would have to be reviewed and probably still being worked on, which is extra effort that if that could be avoided, everybody would appreciate.

Done