Version 1.2 breaks the working rules. Probably, if there would be new features that break any API or any existing configuration, it will be needed to release a new 2.x version, with its upgrade path.
IMHO, v1.2 shoud try to maintain existing rules. New 1.2beta version changes rules condition to use only node types, and lose existing user types rules that worked before when there were only content profiles.
I made a patch that leaves the existing user type conditions for content profiles rules (without any dependency) and adds the new node base rules but with new conditions in order to leave existing rules working and not break any old rule (in other case it would be needed an upgrade path)

CommentFileSizeAuthor
content_complete_rules.patch3.25 KBjcmarco

Comments

pvhee’s picture

pvhee commented

The rule indeed has been refactored from 1.1 to 1.2. We took out the content type configuration because it can be configured independently in rules as well, e.g. your rule can look like "IF content complete >= 100 AND content type = article DO your action".

I haven't included an upgrade path because rules makes it hard to change rules programmatically. However, it might be possible and I'm willing to accept any patches for this.

jcmarco’s picture

jcmarco commented

I understand your approach, in fact it was the first I tried to do.

But migrating existing rules so basic as when user login if user profile is less than 100% completed then do this or that, is impossible to implement because there is no way to link a user type condition with a node type condition. Maybe I am doing something wrong and it can be done, but I couldn't find the way. On this case I agree that actual condition is much than enough and we don't need extra cruft in the module.

I support all the new features and new conditions related with nodes, because it really improves, much more, this so needed module. But you can consider my patch as a feature upgrade that just recover the former existing feature relating conditions with users and not just nodes. In fact my patch just add the old existing condition with the new node condition.

pvhee’s picture

pvhee commented
Status: Needs review » Active

I see your point, and indeed it is a flaw in the rules support in 1.2.

What I propose is a little bit different however: now, the module can either take the node of the current context (new in 1.2), or take the node it encounters without context, this would be the profile node for content_profile, or the first node the user can edit in any other case. Your rule patch would fix the first case, but not the second.

Instead, we could maybe add an option in the rule like 'automatically retrieve associated node for current user' or something else that the user could understand. If that option is checked (default it would not be), then it would take the associated node. This would then fix also hidden assumptions like 'take associated node if content_profile is enabled', which is inherently wrong: imagine you are admin and you want to have a rule fired for every content profile node you edit. With your patch, it would only consider the admin-associated node, and not the node that is currently edited or viewed.

pvhee’s picture

pvhee commented
Status: Active » Postponed

I am marking this issue as postponed right now, as I continue to release a stable 1.2 version (with a warning in the upgrade path to reconfigure the rules). Further rules support and optimization can be included from 1.3 onwards.

pvhee’s picture

pvhee commented
Status: Postponed » Closed (fixed)

1.2 has been released for over 6 months now, without any rules-related problems. Closing this issue.