--

Comments

ndewhurst’s picture

Assigned: Unassigned » ndewhurst

Taking a look at this during Austin code sprint

ndewhurst’s picture

I created an EntityIsOfBundle condition and an associated test that checks a simulated node entity's type and bundle.
TODO: entity type and bundle specification UI (blocked).
See pull request here: https://github.com/fago/rules/pull/51

ndewhurst’s picture

Status: Active » Needs review
ndewhurst’s picture

Assigned: ndewhurst » Unassigned
fago’s picture

Status: Needs review » Needs work

Thanks. Please see my comments at https://github.com/fago/rules/pull/51/files

ndewhurst’s picture

Assigned: Unassigned » ndewhurst

Thanks. Will do.

ndewhurst’s picture

Status: Needs work » Needs review

I revised the code based on fubhy's/fago's comments, and updated the Github feature branch/pull request.

fubhy’s picture

Status: Needs review » Fixed

Thanks! Merged

  • Commit 2a2527c on 8.x-3.x authored by ndewhurst, committed by fubhy:
    Issue #2281111: Porting 'Entity is of bundle (entity_is_of_bundle)'...

Status: Fixed » Closed (fixed)

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

fago’s picture

Status: Closed (fixed) » Needs work

Let's add a deriver as for other entity actions/conditions here.

dasjo’s picture

Assigned: ndewhurst » Unassigned

I'm unassigning this for now, feel free to pick it up whenever you have time to work on it.
Cheers, dasjo

Torenware’s picture

Assigned: Unassigned » Torenware

Picking up this issue for DrupalCon LA sprint

Torenware’s picture

Let's add a deriver as for other entity actions/conditions here.

@fago -- I'm looking at this at the sprint. I'm a bit unclear what problem I am solving here.

The current implementation passes "context" to the Condition plugin

* @Condition(
 *   id = "rules_entity_is_of_bundle",
 *   label = @Translation("Entity is of bundle"),
 *   category = @Translation("Entity"),
 *   context = {
 *     "entity" = @ContextDefinition("entity",
 *       label = @Translation("Entity"),
 *       description = @Translation("Specifies the entity for which to evaluate the condition.")
 *     ),
 *     "type" = @ContextDefinition("string",
 *       label = @Translation("Type"),
 *       description = @Translation("The type of the evaluated entity.")
 *     ),
 *     "bundle" = @ContextDefinition("string",
 *       label = @Translation("Bundle"),
 *       description = @Translation("The bundle of the evaluated entity.")
 *     )
 *   }
 

If I'm understanding correctly, we will still need to pass a context to the condition even after implementing a plugin derivative; the derivative will make "type" redundant, but not the entity or bundle arguments of the condition.

What am I trying to do here?

dasjo’s picture

Issue summary: View changes
dasjo’s picture

Issue summary: View changes

the entity create action is a good reference implementation how plugin derivatives work. i also started writing documentation on this: https://github.com/fubhy/rules-docs/pull/13/files

dasjo’s picture

Assigned: Torenware » Unassigned
Issue tags: +Contributor
fago’s picture

I just added the metadata assertion condition while implementing #2681733: Allow conditions to provide metadata assertions . Some notes on the further implementation:

  • When adding the deriver, we should remove the "type" parameter and check the bundle only. We already have "Entity is of type" as separate condition.
  • We should allow for checking for multiple bundles (OR). I think that was possible in D7 and matches very well with what the EntityDataDefinition can do.
liquidcms’s picture

Is my question this issue?

I am trying to do the simplest Rule i can think of: on node save, display message on site.

on this event: After saving new content (rules_entity_insert:node)

i am trying to set condition for bundle type. Any idea how? in D7 i simply set Content:data selector as node, and select bundle (technically i don't even need to do this in D7 as the Event itself has bundle filter).

In D8 i see 2 similar things:
- entity is of bundle: but it has entity selector which has no value for entity, it does have node, but that makes no sense (and doesnt work). it also has Type, which i assume should be node, and bundle, which is obviously my bundle machine name

- node is of type: with a setting for Node, which i guess would be node (like in D7) and content type (same as D7 except no select list, just text area) - this also does not work.

liquidcms’s picture

ah, perhaps i was being too optimistic in assuming it was the "hard" part of this which wasn't working. I removed all conditions and just tried to display a std drupal message on: After saving new content (rules_entity_insert:node) - and this also fails.

TR’s picture

@liquidcms: What you say you're trying to do in #19 has long been possible with Rules - long before your dismissive post. See for example #2852342-16: creating a simple rule with a content type conditional which provides a complete example of how to do this - simply import that config and you're done. You have cross-posted your complaints so many times that some of those posts, like this, were bound to be ignored. "it doesnt work" [sic] is not helpful to anyone - in this case it's likely that you entered wrong values, but you didn't show your work so we can only guess ... That's the advantage of an example like #2852342-16: creating a simple rule with a content type conditional (which has been part of the rules_examples module for the past year) - it shows you exactly what you need to enter so you can figure out where YOU went wrong.

The ONLY reason this issue is still open is to address @fago's comments from #18, that this EXISTING and WORKING feature should be modified to:

  • Remove the "type" parameter and check the bundle only.
  • We should allow for checking for multiple bundles (OR).

These are "tasks" that should be done. You can contribute a patch for that, you know ... it's far less effort to contribute than to spam complaints over the issue queue.

These "tasks" are NOT bugs or indications that this feature does not work. It does work, and always has worked. But it could be improved, and we're always trying to improve things.