Rules Condition Plugins Can Appear Elsewhere in Drupal UI [#2575697]

I've just found a rather strange interaction between our work in Rules and what happens in Core.

I just tried to add a block to a Drupal 8 install I'm using for Rules 3.x work. Here's what happens when you select the block:

Blocks sees Rules Conditions

Notice that the conditions that appear are all ours :-) This will surprise most users. Certainly, it surprised me.

I'm not sure how Blocks chooses which conditions to display, but I'd guess that we may want to figure out how to make our plugins to not appear unless the users chooses them to be there.

Comment	File	Size	Author
	rules-conditions-get-picked-up-by-blocks-ui.png	72.16 KB	Torenware

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

27 September 2015 at 06:56

Torenware created an issue. See original summary.

Comment #2

mradcliffe

he/him

English

CreditAttribution: mradcliffe at Kosada commented 11 October 2015 at 13:18

Here is the core issue related to this: #2284687: Redesign UI for better management of block visibility

Comment #3

mradcliffe

he/him

English

CreditAttribution: mradcliffe at Kosada commented 11 October 2015 at 16:02

Correction to my previous comment. It's only semi-related. The @todo comment in core misled me. It's possible that core issue could also solve the issue of not showing certain condition plugins, but i think that is going to require an Annotation change in core.

It also looks like Condition plugins are used by page_manager, which means page manager things may show up in Rules as well?

Comment #4

Torenware CreditAttribution: Torenware as a volunteer and commented 11 October 2015 at 19:44

@mradcliffe -- Page Manager indeed uses a similar idea as to what conditions are good for. I haven't looked at their UI, but I suspect it's well designed for displaying a lot of conditions.

The issue for blocks is that it can well display 3 or 4 conditions in the system tops. And if you install Rules, there are a lot more than 3 or conditions that will be on your system. Most of these won't be relevant for Blocks, and just take up screen space.

Comment #5

emclaughlin CreditAttribution: emclaughlin at Genuine commented 12 October 2015 at 14:01

Assuming that it's just that the Block config interface is pulling in all things that are Condition annotations, would Rules need its own RulesCondition annotation (the way it has RulesAction, etc.)?

Comment #6

Torenware CreditAttribution: Torenware as a volunteer and commented 12 October 2015 at 20:03

@emradcliffe -- I know that the intention was to put Conditions into Core, and to use the standard conditions in Rules.

Still, something odd is going on here. Look at the screenshot, for example. The condition you see is implemented in Core by the node module, condition_id = 'node_type'. . Note the "Select a node value" popup?

Two problems:

This popup does not appear if the Rules module is inactive.
Moreover, the popup really shouldn't be there, since the block module is supplying any context that's used there, AFAICT. Probably, the calling module (block.module in this case) should declare what context it exposes, and only conditions that can meet their requirements should appear there.

The second one is sort of a puzzler; I'm not sure if this is something Rules is doing to Blocks intentionally, or if it's some weird artifact of the two modules interacting.

We also have an interaction bug I've discovered: see #2587179: Place block operation in the modal Place block dialog does not bring up config dialog. The guy isn't taking it very seriously, but I'm pretty sure this is a Core issue nonetheless.

Comment #7

Torenware CreditAttribution: Torenware as a volunteer and commented 13 October 2015 at 19:54

After spending the last couple of days looking at how our plugins look when used with Blocks, some observations.

We should probably override buildConfigurationForm() and so something that looks more reasonable as a default.
We may want to figure out some way to keep some plugins from appearing at all. I'm not sure if that can be done at our end, or if that requires a change in core.
We're using pop-ups for entities, but we might do better either to just put a text field, or if we can, do something like the D7 data selector widget.

IMNSHO, of course :-)

Comment #8

Torenware CreditAttribution: Torenware as a volunteer and commented 30 November 2015 at 20:34

This turns out to be related to #2591177: Rules context processing coerces most context types to 'any'. Because the plugins were misreporting the arguments they required, inappropriate plugins appeared in the UI.

Since #2591177: Rules context processing coerces most context types to 'any' is now fixed, so will this be.