Components: enable / disable

I don't think this is often needed. You could clone the rule, disable the original and experiment with the clone?

This is indeed not a thing which is of higher importance when you use Rules to send a message, but when programming long algorithms it would be really handy to quickly enable/disable some actions. Let's don't narrow Rules to the former :)

Here's why I think it would make sense to implement this behavior on components:
* Components are configurations, so they already have an 'active' field available.
* Actions would be more difficult to disable, afaict.
* It would be alot cleaner this way, as I show in the described mockup.

Here's why I'm probably wrong:
* As you'll see below, the UI change assumes an inheritance model that I don't fully address. For example, if you disable a component from within one rule, should it be disabled in another?
* Being able to disable any element of a configuration would address ^ more thoroughly and could make more sense, especially because everthing is read just the same, as plugin instances with parameters.
* I learned a lot while investigating this, and I see even more clearly how poorly I understand the Rules Engine and Plugin API, so that leaves me with no doubt that this is, at best, half baked.

Continuing with my original thought: by reusing rules_config's boolean 'active' state with components as it is used with reaction configurations, and then "sliding this in the existing evaluation logic", it would be achievable without too much effort... (ha)

Here's what it could look like:

• Component overview screen: use the same split view as the reactions overview screen, Active / Inactive groups
• Rule configuration screen: add enable / disable links beside these component elements

I tried to implement this, or get as far as possible. Here's what I tried and thought:
* I manually tested "disabling" a component in sql in order to see if it would have any change, whether or not it ran, was displayed, and was still editable. No change.
* Then, I tried hacking Rule's component cache in rules.module 2 different ways. One way, nothing happened, and in the other, though the component continued to be shown in the overview screen and was editable, when attempting to run it, Rules said that the plugin was unknown.
* Then I read the API more closely to learn more about components in order to eventually alter Rules' execution flow and control logic.
** There's a big gap in my understanding about Plugins and Abstract plugins.
* My final idea was to incorporate the 'active' -> 0 as a new 'inactive' $setting of RulesAbstractPlugin, which would be connected with an exception during checkParameterSettings() in the hope that this would be a graceful fail, which is potentially what we'd be shooting for.

I'm very unsure if this still requires even more changes, for instance to cover immport/export. I definitely think it's more involved than I initially thought, but I still think it's a cool improvement to leave open for the future.

Here's what it could look like:

• Component overview screen: use the same split view as the reactions overview screen, Active / Inactive groups
• Rule configuration screen: add enable / disable links beside these component elements

Agreed with both propositions.

isn't this a duplicate of #1288874: Provide disable/enable Link or Checkbox for Rules Conditions & Actions ?

Just to add my two cents worth to this ancient request:
I have the need to replace a Cron-scheduled rule (component) with custom code. In my module, I wanted to disable the rule but leave it there for documentation. Components seem to ignore both the "active" and "status" flags in the database (rules_config). It appears that the only option I have is to delete it entirely, which I would rather not do.

I'm marking this as a duplicate of #1288874: Provide disable/enable Link or Checkbox for Rules Conditions & Actions