List of conditions includes Core conditions which do not work with Rules

We had to fork the actions api, but as far as i know we didn't have to fork the conditions api for rules yet. Ideally we should try to stay compatible which is why they show up.

Is there something missing for the core conditions that they don't work with rules?

@dasjo just a quick look at the differences between: \Drupal\node\Plugin\Condition\NodeType(core) and \Drupal\rules\Plugin\Condition\EntityIsOfType(rules)

Here is what I think is happening
You can use NodeType in Rules but...

1. You are given form with just "value" this is the Node context specified in NodeType. Rules does seems to understand this from the NodeType's annotation context section because if I try to use data selection and select a none node value it will warn me. It has not label or description because EntityIsOfType uses "label" and "description" in the context section of the annotation.
2. The type is not available to choose because core conditions use \Drupal\Core\Condition\ConditionPluginBase::buildConfigurationForm to select this. The Rules UI seems to not call the this but rather figure this out by Conditions contexts.
3. NodeType does not use the context annotation to define "type"(bundle)
4. \Drupal\node\Plugin\Condition\NodeType::evaluate() does get called but because the configuration for the condition was never set it always returns true.

So obviously Rules conditions are more flexible and don't rely on hardcoded forms. So I am not sure if Rules ever calls \Drupal\Core\Plugin\PluginFormInterface::buildConfigurationForm for the conditions or uses the form logic at all. If it does not one way to make Rules with core conditions would be:

1. have \Drupal\rules\Core\RulesConditionBase override all the methods from \Drupal\Core\Plugin\PluginFormInterface with empty implementations.
2. Rules could addition to it's current logic call methods on PluginFormInterface. This is would have no effect for conditions that extend RulesConditionBase
3. Core conditions could use their simple conditions. Maybe somehow label these as less dynamic.

This is my first look at Rule 8.x so I could be totally off 😉

Here is patch that simply gets the configuration form for core conditions to show up. The configuration doesn't save.

Just a note, most(all?) of the conditions are duplicated with conditions that Rules provides. So you might just want to remove the known ones.

Yeah I agree we should just hide the conditions which we replace with better alternatives.

For the others, just adding in the form + making sure it saves correctly should be the way go. Of course we need to figure out a common code path somehow here. Maybe we could just have the Rules' generated form be loaded in the same methods as core uses?

Setting to needs work as this is not finished.

I guess it would be the best for now to just hide those conditions, otherwise there will be continuous support requests and bug reports with error messages that result form trying to use Core conditions.

This patch hides the non-working core conditions from the Rules UI.

This indeed hides the 'other' category and the conditions in it. Applied cleanly.

When or how the to-do in the patch will be resolved is a question I still have though.

I committed this patch, primarily for the reason stated in #7.

But I'll keep this issue open to address the larger problem of using core Conditions in Rules.

The last committed patch also all default Block visibility conditions. Also, Rules conditions always are in the Block visibility conditions selection.

This patch just remove applied changes.

It looks like this check should be made in the ConditionForm rather than in the ConditionManager, that way it will affect only Rules. I will post a new patch later. This issue is still "Needs work" for all the other things that need to be done - there is no new patch to review.

The problem of Rules conditions showing on the Block settings page is the subject of #2675698: Ensure compatibility with core block UI

You don't need to post a new patch, the changes can be reversed by applying the old patch with patch -R.

@dinazaur: Try this - this should not remove the default conditions from block visibility, but should hide the core conditions from the Rules UI.

I reverted the commit made in #10 to fix the Block visibility problem, and added the changes in #15 to restrict the core Conditions using the ConditionForm rather than the ConditionManager. This patch was reviewed and tested by several people in #3160347: Option of block page visibility is missing.

Back to NW for the rest of it...

#15 worked for me on drupal 8.8.8 and rules 8.x-3.0-alpha6

one more
#15 worked for me on drupal 8.8.8 and rules 8.x-3.0-alpha6

Thank's very very match. #15 work but I wasted all day wondering what it was, and I didn't know how to ask google. Thank you again!!!!

#15 helped (Drupal 8.9.2 / Rules 8.x-3.0-alpha6).

Thanks #15 works for me with Drupal 8.9.6 and Rules 8.x-3.0-alpha6

#15 worked - thank you

#15 worked (Drupal 8.9.10 and Rules 8.x-3.0-alpha6)

#15 worked on 8.9.12 Rules 8.x-3.0-alpha6

Changing this to reviewed and tested as the past 7 people have tested.

Read the issue - the patch was committed 6 months ago . .

I can't apply the patch on the D8914 + rules 8.x-3.0-alpha6

sited8/modules/contrib/rules$ wget -q -O - https://www.drupal.org/project/rules/issues/2927132#commen t-13761341 | git apply
error: unrecognized input

what is missing ?

Exact. The right command is:
/sited8/modules/contrib/rules$ wget -q -O - https://www.drupal.org/files/issues/2020-07-23/2927132-15- remove-other-conditions-from-ui.patch | git apply

Thanks