Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.In OG7 you can associate a fieldable object with groups using fields API. This means that node2, node3 and user1 can be associated the same way to node1 which is a group.
/**
* Set an association (e.g. subscribe) an object to a group.
*
* @param $obj_type
* The object type (e.g. "node" or "user").
* @param $object
* The object to set the association.
* @param $groups
* Keyed array of the groups to subscribe the object.
*/
function og_set_association($obj_type, $object, $groups = array()) {
//....
foreach ($groups as $group) {
//....
$object->og_audience[FIELD_LANGUAGE_NONE][$key] = $group;
$save = TRUE;
}
if ($save) {
og_invoke_event('og_set_association',$obj_type, $object, $groups); // <-- Pass the object to Rules.
call_user_func('field_attach_' . $op, $obj_type, $object);
}
}
As you can see from the above code, I have a problem with defining hook_rules_event_info() as I need to define an argument of type object. Apart of creating a "fieldable object" data type, maybe there should be a way for Rules to know what this object it and allow the actions, condition accordingly.
Comments
Comment #1
fagoIs there a direct association to an entity for a certain group? If so, I'd suggest creating one event per group.
I don't think it would make much sense being able to deal with a variable X where the entity type isn't known as there won't be much you can do with it. A possible way would be a condition to check the entity type, but that's not so clear/clean anyway.
Comment #2
amitaibuAs you can see in Field API, along with the object itself, we also pass the $obj_type, so we can identify the object. I have an idea how Rules can handle it using a wildcard argument. This argument is like a joker - it's just a place holder, that on runtime will be set to a specific argument. So for example:
1) For simplictity, let's assume I'd like to associate a user to fieldable object (node, user, etc').
2) Create a rule set with 3 arguments:
- user for the user account
- string for the obj_type
- wildcard for the object
3) Create a rule with condition
obj_type == nodeand the action will be "Set argument as data type", which will tell Rules, that the object is a node - opening the door for all node related conditions and actions.Comment #3
amitaibuI think this can be solved by having an action "Load entity" that accepts the obj_type and object ID.
Comment #4
fagoI agree that we need something like that. Already rules 1.x supports the wildcard * as well as an array of possible types, so that might be a way to go for d7 too. Just build up an array of possible entity types.. Though I'd prefer to support this quite common case "entity" a bit better, like supporting something like 'type' => 'entity'. I'll tackle this these days.
Still the problem remains having 2 arguments (type), but the uses should only choose 1. We might pass an array ($type, $entity) as single argument or just set the type in the entity object: $entity->entity_type = 'node'; Would do you think?
Comment #5
amitaibu> Already rules 1.x supports the wildcard * as well as an array of possible types
I'm not sure I follow/ know it - where is it in rules1?
But anyway, I no longer think we need it. "Load entity" is the way to go. Possible ways:
1) Have two actions: The first is "Load entity" and the second is "Set entity" (<--bad name). that will know to consider the entity argument as a node argument.
2) Have the "Load entity" automatically set the argument to be of the correct type.
3) Have three actions: "Load entity", "Set entity" and "Load entity and set" (<-- again bad name, but for better UX).
Comment #6
fago>I'm not sure I follow/ know it - where is it in rules1?
For an action just specify 'type' => '*' or 'type' => array('node', 'user')
@2) Have the "Load entity" automatically set the argument to be of the correct type.
Something like that won't work, because we need to know the entity type beforehand, when actions should make use of it. Thus we can provide a condition to check it: "Entity is of type" -> Then rules knows the type and can provide the right actions.
Comment #7
fagoComment #8
fagoOk, I've planned to support the following data types in rules:
The ones from the entity metadata module, being:
* - text
* - integer
* - decimal
* - date: As timestamp.
* - duration: In number of seconds.
* - boolean
* - uri: Be sure to always return absolute URIs.
* - entities - You may use the type of each entity known by
* hook_entity_info(), e.g. 'node' or 'user'.
* - lists (list)
I think we should support some sort of inheritance which is useful for type matching. E.g.
text is-parent-of decimal
decimal is-parent-of integer
text is-parent-of uri
"entity" is-parent-of
For remote data something like that can be used:
-> add a "rdf" entity
-> support rdf in rules
I think about adding also generic actions for data saving, data fetching, deletion and maybe also creation.which would have to rely on the rules data wrappers.
So you could do actions for an argument 'entity' - do you think that suffices? Or should we also add something like "fieldable entity" as not all entities are fieldable?
Comment #9
amitaibu> inheritance which is useful for type matching.
I didn't understand what you mean by that.
> Or should we also add something like "fieldable entity"
Maybe it can be a condition - but that might make the learning curve even stipper on non-programmers using Rules. I think entity is enough (anyway, you can't set a field on a non fieldable entity).
Comment #10
fagoyep, entity should be fine. :)
@type-matching:
Write an action having an entity parameter, rules offers you to pass a 'node'. -> It needs to know which types are "compatible".
Comment #11
fago@entities:
I've now implemented a data type 'entity' and the needed type matching. (see http://github.com/fago/rules/commit/db298bd882b11d5920b0f2aa69171152fa4d...) - so actions for 'entity' are already possible :)
So now the data type system only misses support for lists and parametrized data types (needed for lists, rdf,..).
Comment #12
mitchell CreditAttribution: mitchell commented@fago: How is entity support going? Which data types are supported/unsupported?
We need a new status: 'postponed (users need more info)'
;)
Comment #13
fago;)
The data type system is ready now. It supports all entities out of the box + the stuff described with hook_rules_data_type_info(), which may be used to describe further non-entity data types. I've removed the general concept parameterised data types though, as they were not necessary any more. Lists still can use the list notation as entity_metadata does.
Comment #15
fagoNow you can do easily rules related to a field:
see http://twitter.com/the_real_fago/status/15489418172
-> I guess we could need support for some generic entity events now!