[Meta] Merge Conditional Rules

IMHO, here's what makes the most sense...
* Separate switch and while from this issue. This will allow us to also focus the discussion and help with the docs, hopefully, ..especially as people ask for concept clarifications and about possible improvements.
* Turn this into "[Meta] Add Predicates & If-Then-Else Rules".
* Make your own personal fork of Rules (as opposed to a short term, per-issue sandbox).
* Make additional branches targeted for each meta issue, or more specifically each merge point. (I added some supplemental info to the issue summary with links that may be of use; they can be thinned from the issue summary in another revision.)
* Other developers can either fork your branches to make improvements and work on the issues as well, or they can bypass your fork and implement the same change with a competing approach continuing from each merge point.

1.
Continuing the assumption, you'll no longer be working downstream of Rules. Your work will be merged to the canonical Rules repo (fago's). So, there shouldn't be any need for temporary workarounds as long as the commit sequence follows the dependency order. Otherwise stated:
* Just about every commit will be on track for a straight merge within Rules (barring any unfortunate log rewrites or commit compressions).
* In the last issue, by "encapsulates the commit flow", what I mean is that almost all your work chronologically leading up to that most recent track was dependent on a sequence of commits. If you had a view of each project's commits and issue comments that you posted with patches, then, AFAIR, you'd have a chronologically ordered, atomic sequence to commit each code iteration that wouldn't have any todos.
* I even hope your work in #1666802: Keep embedded elements under compatible containers in container UI could be included as iterations for Rules' own blame records.

2.
My vote is to merge Conditional Rules' implementation of hook_rules_plugin_info() with Rules' own implementation in rules.module. I'm also thinking that these will change with [#12345: Convert Rules to PSR-0]. See also, https://drupal.org/sandbox/eclipsegc/1663586

Between modest reform (included submodule); comprehensive reform (fully baked in); or status quo (contrib://rules_conditional), my preference is the comprehensive reform. As stated above, my preference would be to save switch and while for separate issues (and possibly separate release cycles), for the sake of issue tracking and/or iterative UI changes. If our goal is to get them all in within the same release, then each user base should test them concurrently and work on the docs to make this all happen.

It almost seems that alphabetical would be a very easy to grasp order, but UX feedback would be nice. What makes sense to me is (action|conditional|loop), and then (action|conditional|loop|switch|while). Leading with action is important, IMO.

3.
I'm not entirely understanding, but I think we at least need a separate issue for while (I'm sure my bias of separating things as best as possible is very apparent). I think since adding predicates would obviously be done first, it should at least be possible to separate While as a sub-issue of this meta one. Maybe even an initial RulesConditionalElement and RulesConditionalPredicateElement could be a separate sub issue, unless it would be better for those to go in together with the first implemented plugin (if/then/else). In any event, this approach is mostly for the purposes of organization and historical recollection. I'm not trying to overburden you, and my hope is that this mostly stretches your git skills rather than your patience. :) Please slap me in check if I'm going overboard with recommendations. :)

Side question: Would it be a good idea to rename RulesConditionalPredicateElement to RulesPredicateElement with Conditonal plugins as extensions of that abstract class? I think what I'm trying to ask is, are non-conditional plugins able to use predicates? I understand that predicates are directly connected to conditionals, but I don't entirely see what this change will mean yet for broader use.

Side joke: This kinda makes me want to create a follow up for #393410: Icon/Graphic for Rules module to make the furthest ball also airborne ;)

Edit 1: Fixed close tag.
Edit 2: Fixed issue link to icon issue.

> How does this look?
It looks lovely!!!

> "the main sandbox fork"
> "my sandbox"
I want to try to nail this down. Based on frando's point in C, I take back my recommendation to create your own personal Rules sandbox for the long haul. It appears you're following frando's recommended workflow with "Rules conditionals fork" because it is paired with this issue, so I just want to ask if you plan on making separate forks per each meta-issue. His point about multiple branches in a single repo makes sense, but it seems a tad counter-intuitive and cumbersome to me, unfortunately. So, are you comfortable with this workflow? Also, for the record, klausi confirmed that working with sandboxes is appropriate (though, in his opinion, a little unnecessary) as long as patches are also used for review and merging.

> RulesConditionalElement
I'm afraid I probably won't have too much more to say about the class architectures. Programming doesn't come easily to me, so I'm happy the names observation was at least helpful. :) Your descriptions are also a bit too succinct for me to easily grasp how all this works. I primarily hope to understand the difference, conceptually, not code-wise, between conditional and non-condition plugins (but, just to note, I'm not asking you to change your descriptions at all. they're incredibly helpful and I appreciate good code details). So far, I'm just confused as to why RulesPredicateElement extends RulesConditionalElement and not the other way around. I think you answered what I was investigating with "the scenario of a non-conditional plugin using predicates is kind of a non-issue".

> We could create an issue to polish the terminology in full.
Perhaps in the paired sandbox? This would seem to match fago's approach for D8 Entity API through http://drupal.org/sandbox/fago/1497344

> it'll probably be a good idea to make a decision now as to whether the predicate UI should be implemented as-is for the moment or actually incorporate factory UI
The way I was thinking about it was to get the UI controller to the optimal state, then fork from there. For this issue, please, in the meantime, at least start on writing up about predicates and predicate UI in two more issues, because that would be very helpful to getting to the bottom of what exactly each one is.

Cool. So, that sorts out all the doubts you had initially? (at least until fago can give definitive answers) I'll standby till you want reviews or any other feedback. Thanks again.. and again!

Thank you for this effort, I can't wait for this to become a part of Rules!

First off, thanks for all your great work on Rules and your extension modules. I really love to see you experimenting with the API boundaries and doing great jobs like the Views Rules modules and working on the Conditional Rules stuff.

Now, to the issue. A proper summary would help here - I've been a bit confused of a all the Git merging discussing issues linked? I'm not sure this belongs here, but yep we are using Git sandboxes to maintain bigger patches.

Anyway: I think it's better to have Conditional Rules developed in its own project for various reasons:

First off, I'm not sure that's functionality our main audience - the mass of Rules user - need. I'd be interesting to know, but I've the feeling that he mass of the users uses Rules for rather simple stuff, like sending some mails and some automated setting of values. Those users would be confused with all the different while/switch/if-then-else options that require you to know all those programming concepts.

Next, I feel that we've not even made our basic homeworks in Rules yet. The module API does quite a bit more as what is exposed in the UI and the UI suffers from quite some basic UX troubles with already the *simple cases* we've to get right first. Then, the second *very* important point we've not properly achieved yet is: Provide an easy to use and *integrate* API framework for conditions, actions and reactions. That is, modules should be able to easily leverage the framework to build the conditional-UI of Rules into their own - it's too hard and complicated as of now.
Thus, my feeling is that what we've to concentrate in the nearer future on UX improvements + a strong API. Building a more powerful UI-based programming tool out of Rules is contrary to these goals as it complicates things a lot.

Lastly, for the Conditional Rules development pace I think it's better for it to stay out side of Rules. That way you are more free to elaborate, try things and remove things if they don't work out. As you know Rules is the base for quite some stuff and needs to stay very solid and stable, so for the core of Rules we cannot experiment much but have to provide a solid way forward.

That said, I'm very happy to see you working on this and of course I'm happy to work with you to fix and improve issues in Rules to facilitate the development. Something in the lines of #1681510: Add plugin factory to UI makes a lot of sense to me, as well as possibilities to convert plugins (e.g. move from an Action Set to a Rule set), what will be needed the more the more great plugins are out there.

For UX the Conditional Rules could actually help to solve some common troubles people have when a rule isn't enough and you need to go with lots of components. Still, there are other possible ways to solve this and I'm not sure this is the right one - so let's see.

Of course, I'd be happy to add a prominent link to useful Rule-extensions on the project page, so it gets the visibility it deserves. Let's do that once we've a nice release working without patches - so people can go and try it. Then if it turns out that Conditional Rules is a no-brainer addon for Rules I'm happy to revisit this issue in the future :-)

So, won't fixing it for now.

@fago: Thank you! I've been waiting anxiously for your feedback on this issue, and there is so much valuable feedback in #10. So, I will build on it and continue to do my best to make this a valuable issue by focusing on the missing pieces you've illuminated.

To validate @zhangtaihao's contributions and my own investment in facilitating users' access to this functionality, I will echo one of your last points:

For UX the Conditional Rules could actually help to solve some common troubles people have when a rule isn't enough and you need to go with lots of components. Still, there are other possible ways to solve this and I'm not sure this is the right one - so let's see.

And, I read you loud and clear that the case for a merge has not yet been made.

> A proper summary would help here
This is the primary reason for my status change.

> I've been a bit confused of a all the Git merging discussing issues linked? I'm not sure this belongs here
I apologize. I placed those links there temporarily, as part of my comments in #1, to help @zhangtaihao while the git processes were still being discussed. I did not intend to leave them once the issue summary was fixed.

> I think it's better to have Conditional Rules developed in its own project .... That way you are more free to elaborate, try things and remove things if they don't work out.
The project is actually very stable already; there is only 1 unconfirmed bug, and it has a very healthy adoption curve. My intention in #1666834-3: Release roadmap (stated in the first paragraph up till the last sentence) was to work via this avenue so that the necessary Rules improvements would have greater visibility and validity. I think this is working out well, even now.

> I'm not sure that's functionality our main audience - the mass of Rules user - need. I'd be interesting to know
This is a very reasonable prerequisite for a merge. #1689358: Just what rules needed!! is but one voice, so I think a real user study may be in order. In the meantime, we can still work on the issues that you are comfortable with merging and prepare this one for another review. This will work to the benefit of both user bases.

> Those users would be confused with all the different while/switch/if-then-else options that require you to know all those programming concepts.
If-Then-Else is what I think most users are interested in, followed by While in a distant second. #3 clarifies the plan to separate Switch/Case and While in followups exactly for the reason you stated.

> modules should be able to easily leverage the framework to build the conditional-UI of Rules into their own - it's too hard and complicated as of now.
I think this is what Predicates is for, but I would prefer to seek @zhangtaihao's response to see where you guys can agree on API improvements that we can review here and in related issues.

> That said, I'm very happy to see you working on this and of course I'm happy to work with you to fix and improve issues in Rules to facilitate the development.
This and countless reasons more are why I think you are an excellent maintainer. Thank you for your kindness and collaboration even when you are strict!

Supplemental info

> Those users would be confused with all the different while/switch/if-then-else options that require you to know all those programming concepts.

I think it is harder for most users to grok the term of 'Conditional' over natural demonstrative language such as if this then that... I think it by far more confusing to a novice and beginner to make two rules for a simple branch condition ('if this, then do a thing, else do another thing' for those of you who don't know what a branch condition is.) I just spent an hour explaining it to one of my clients who wants to manage his site himself last week. His major complaints were that the interaction of the rules wasn't very obvious even through we grouped them using tags, he didn't like having to set the filters to events and tags to see his sets of rules. He also complained about having to move to so many screens, and complete so many forms, especially for rules which required very similar conditions.

I think it is condescending to believe the most users who use Drupal can't comprehend if/then, while, switch, etc. They may be computer science terms, but most english language speakers know these words and their meaning. If someone has installed Drupal and is in a position to be customizing rules, you might as well give them the benefit of the doubt... Even stacks and queues are relatively simple to explain to non-programmers. They won't get the implementation in C or PHP, but they'll definitely get the concept quickly.

If a streamlined user experience is your goal, there are ways to highlight commonly used functionality without limiting the capabilities which are exposed to the user interface. The first ideas that come to mine are emphasizing and de-emphasizing options using font sizes, positioning, and hiding.

I think rules should do away with the separation of conditions and actions altogether and role the whole functionality into actions as is done in Conditional rules.

I would like to add my opinion here since I see that months are passing and there are no more feedback on this. I think that zhangtaihao approach is very interesting. Rules UI is somewhat hard to understand, and considering fago's comment on if/then/swich elements being complex, I don't know if they are more complex to undertand than "loops".

Everytime I use more Rules to make the site to react to more complex things. I even use PHP inside some rules (although calling my own API functions for a better code management). So the assumption that the present UI is good enough to "non programmers" is not clear to me. I use Rules instead of coding more complex modules because for sending an email according some conditions or scheduling node unpublishing is far more comfortable on Rules than trying to be an expert on hooks and drupal API. So a bit more complexity on being able to organize conditions and actions would increase the capability of Rules to help me build even more complex solutions.

All in all, I find "Conditional Rules" a very interesting contribution to my other extending-rules modules. I would vote to consider it part of the core module although as a separate module on installation just in case some users wouldn't go too far with it (as the Scheduler). But I wouldn't like to invest to much time on it to see that maybe it's not well supported. Well, just my two cents :-)

PD: I would love to know more about if this integration has evolved on the last months :-P

Remove git notes

Thank you for this brilliant Conditional Rules module and I strongly hope this would be merged into the Rules module as I found it Indispensable in many scenarios.

Earlier I'd been scratching my head on how to use the Rules module to automatically create a new user account for visitor who has submitted the contact form built with the Entityform module. I'd been thinking of the logic as follows.

a.) check for the existence of email and if not
b.) check for the existence of username and if exists
c.) loop thru a self-incremental counter to find an available username + counter and then
d.) create a new user account

However, Rules is too simple and no Else condition. Without Else, I need to create lots of components, I guess there will be around 30-40 or even more for branching. Mostly for Else condition and all these would degrade the server performance due to redundant checking in each component. At that time, I really wanted to give up Rules until I met Conditional Rules module which made my logic of workflow a reality with Conditons in Actions plus While statement besides Else condition.

Attached is the prototype created with Conditional Rules and just tested to be working and I'm so happy with it. Conditional Rules had empowered Rules to the greatest level of usability. At last, I eagerly wish Conditional Rules to be merged into Rules coz it's really an indispensable module with Rules.

Perhaps, can create a checkbox to enable Conditonal Rules for Advanced Users upon merger if Rules still wants to maintain a cleaner and simple interface for normal users. If Conditional Rules is not ported to Drupal 8, it will be a great loss then.

Hi,
Would Conditional Rules be merged into Rules module in Drupal 8 ? Frankly, I always find the Rules module not usable without Conditional Rules which has become a must for every project. It'll be really disappointing if Rules in Drupal 8 doesn't include the functionality of Conditional Rules. Thank you.

hello!

absolutely agree. i think the rules conditional module deserves a much more prominent position and should imho be shipped together with rules (just like the rules scheduler).

initially, ive been spending many hours setting up a whole bunch of (complex) components and rules where i could just have used the conditional module considerably reducing the amount of components and overall complexity. after ive ran accross this great module im using it now for many cases and dont want to set up sites without it.

Rules certainly is one of my top 3 drupal modules outthere. so much you can do with it. conditional rules makes it even more powerful!

just my 2 cents.

in a way this might happen for drupal 8 - we call that concept "inline rules", not sure though if it will match all the functionality provided here and how the UI is going to look like. if you are interested, talk to us at drupalcon in person http://d8rules.org/news/d8rules-updates-bof-sprints-drupalcon-amsterdam or via the issue queue

Conditional Rules Module made life Million times much simpler. With the addition of Conditional Rules module, I'd easily implemented many conditions which are NOT practical or just Impossible with the core Rules components

I found the core Rules components very confusing / verbose, not practical for nested / branching conditional logic, otherwise the entire conditional flow will become unreadable / unmanageable.

I 100000x wish Conditional Rules module to be ported otherwise I'll have no clues of implementing the same conditions in Drupal 8 as I still found the Rules components unusable in this aspect. Thank you for the hard work.

Guys, all of us wish Conditional Rule to be a part of Rules, but wait. Is that too hard to just install a module?
Just think of this module as of API module and relax :)

this won't happen for d7 and as OnkelTem mentions, just by installing an additional module you can already get all the functionality.

as mentioned in #18, we will evaluate this again as part of porting rules to 8.x.

this has to wait for the UI to get implemented though - #2245015: [META] Rules 8.x Roadmap

Great to hear Conditional Rules module to be ported to D8. The original maintainer seems having been inactive for a long time. We're afraid of losing the great module in D8 as it has become indispensable for every drupal project. Thanks again.

hello,

@ additional module:

for me it was not about installing the module - takes a few seconds with drush. it was about KNOWING that it existed at all. if it was an addon (like the scheduler - which i personally use much much less), im sure many people with less experience would love it (and this would of course also be good for rules itself).

@coreteamvn,

Agree, our main concern is whether the Conditional Rules module to be ported, not about taking extra step installing it. If it was merged & integrated in Rules, it will be well-supported in the future as we all find it indispensable for all projects. (sorry, I still find components very tedious & verbose for workflow, only Conditional Rules module can streamline the entire process, really cut down million works :) ).

While I know little about D8, I had a chance to trace both Rules and Conditional Rules modules and I can say they don't rely hard on Drupal, instead - they provide unique and pretty complex classes structure. That said, I don't think porting to D8 will be an angry task. Just my two cents.

Almost off-topic. I remember once we with Mitchell have been discussing a better approach for programming using Rules. Then we'd come to conclusion that the best thing would be a pseudo code editor with code completion. What a sweat dream! Wish it will be implemented once.

Please, everyone who uses Rules Conditional, take at look at this Issue and try the patch: #2423701: Cloning a rule/component with RulesConditional elements doesn't update their parent correctly

Is this the only way to test if an action "check entity by property" fails?

@sonicthoughts

Is this the only way to test if an action "check entity by property" fails?

Rules Conditional just extends "Actions" with "conditional" actions — things which you could only use in the "Conditional" block in stock Rules. So it won't give you any additional knowledge of something. But since it has ELSE feature, you can use it to add behavior in case some test is failed.

To repeat what @dasjo said in #12:

This won't happen for d7 and as OnkelTem mentions, just by installing an additional module you can already get all the functionality.

as mentioned in #18, we will evaluate this again as part of porting rules to 8.x.

this has to wait for the UI to get implemented though - #2245015: [META] Rules 8.x Roadmap

I'm not sure why this issue wasn't moved to 8.x-3.x back then - maybe the issue tag didn't exist at that time.

Regardless, if you would like to see this happen please help out and contribute!