This needs some real world tweaking for compound fields and probably language, but I think this is actually working pretty well at this point.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

amitaibu’s picture

Status: Needs review » Needs work

Why are we adding the field per bundle and not the field itself. Like this I can have an access rule on the field, regardless on what bundle they are attached to.

+++ b/plugins/access/entity_field_value.incundefined
@@ -0,0 +1,189 @@
+    $columns[] = _field_sql_storage_columnname($field_name, $column);

Why do we need this, and not get the info from the field_info()?

+++ b/plugins/access/entity_field_value.incundefined
@@ -0,0 +1,189 @@
+  $form['settings'] += (array) ctools_field_field_invoke('form', $entity_type, $entity, $field_name, $form, $form_state, array('default' => TRUE, 'language' => $langcode));

Wrong function should be -- ctools_field_invoke_field()

Also I'm not getting the settings properly, haven't dugg enough to see why ;)
btw, just so #1299838: Field Comparison Access Plugin

EclipseGc’s picture

Status: Needs work » Needs review
FileSize
7.73 KB
$columns[] = _field_sql_storage_columnname($field_name, $column);

is being used to handle our values that get serialized into the plugin $conf in the same manner as how core expects them to exist.

The plugin is calculated per bundle because all the code I've seen for field display actually really really cares about the bundle it's attached to (even if it can be attached to multiple bundles) and rather than fighting this trend or trying to calculate it some other way, it seemed most efficient to simply calculate this in the children process. Since we don't actually have an entity context that's legitimately populated until we're actually doing the access check itself, this just seemed much easier. Yes it does give you a LOT of potential access plugins, but I think that's probably "OK" all things considered.

My example scenario for this has been taxonomy term entities with a drop down select list field attached. I expect this will work with select lists, radios, textfields/areas and node/user/term references for sure. Things like checkboxes, and anything multi-value is probably going to need a bit (or a lot) of work to get working. Likewise I am leery of compound fields like address field, but I think this is probably a really good first pass.

EclipseGc’s picture

also, sorry about the call to ctools_field_field_invoke(). Merlin and I both wrote competing code for this in the same time period and apparently I didn't reroll my patch after updating to use his code.

amitaibu’s picture

Probably also worth removing file/image options?

stevector’s picture

I'm discussing this patch with Eclipse in IRC at the moment and focusing on ctools_entity_field_value_ctools_access_summary().

Here is an updated patch that simplifies that function.

EclipseGc’s picture

Yeah, that's not going to work because there's an alter in there that other modules use, and they expect a full entity with ids and everything to be coming across... which we are NOT passing. heh...

andypost’s picture

So can we have "field is empty" with this patch?

stevector’s picture

Assigned: EclipseGc » Unassigned
FileSize
8.61 KB

I tested this patch on a site with nearly 300 field instances. When ctools_entity_field_value_ctools_access_get_child() was called in the front end, it called ctools_entity_field_value_ctools_access_get_children() which loaded all 300 potential child plugins.

I think the helper function in this iteration can get us the best of both worlds.

bryancasler’s picture

#8: I can't believe how well this worked. Super impressed.

merlinofchaos’s picture

Priority: Normal » Major

Upgrading priority. We really need this.

droath’s picture

I wasn't able to get the field value access plugin patch to fully work when comparing context field values for a visibility or selection rules in panels. So I made some minor adjustments to the current patch. I'm not a ctools expert so please let me know if I'm missing something, I really only focused on the initial access check function. So there is still work to be done.

This was tested to work on both textfield, and radio/checkboxes field types for both visibility and selection rules in panels.

EclipseGc’s picture

Status: Needs review » Fixed

looks like this was committed!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Peter Bex’s picture

Status: Closed (fixed) » Needs review
FileSize
983 bytes

There's a small bug in this code that means the access field's value gets chopped off to the first letter. Here's a patch that fixes that.

andypost’s picture

+++ b/plugins/access/entity_field_value.incundefined
@@ -197,7 +197,7 @@ function ctools_entity_field_value_ctools_access_summary($conf, $context, $plugi
-        $entity->{$field_name}[LANGUAGE_NONE][] = $conf[$conf_key];
+        $entity->{$field_name}[LANGUAGE_NONE][] = array($column => $conf[$conf_key]);
       }
     }
     $string .= " @{$column} equals @{$column}_value";
-- 
1.7.9.1

maybe better

$entity->{$field_name}[LANGUAGE_NONE][$column] =  $conf[$conf_key]; 
Peter Bex’s picture

That doesn't do the same thing. There's no field delta element in your code, so it results in entity->field[und][value] = 'foo' instead of entity->field[und][0][value] = 'foo'. This also means multiple values are dropped.

merlinofchaos’s picture

Status: Needs review » Fixed

I committed this.

However, after I committed this I realized we probably should be using field_get_value() or whatever the proper value retrieval function is. So this probably needs some more work, but this fix will work in the interim.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

andypost’s picture

There's a lot of bugs introduced mostly for taxonomy fields because plugin make assumption that fields have their value in 'value" column and field consists of only one storage column.
Follow-ups:
#1601062: Field access plugin ignoring selected value
#1520036: Notices thrown when taxonomy used for selection criteria
#1630820: entity_field_value is completely broken

drewish’s picture

I ran into problems with this throwing a bunch of warnings if the field is marked as hidden on the node. It also seems a bit too limited...

In my case I've got an image and video URL fields. When there's a video URL the image gets used as a thumbnail so I want to hide the image component and only display the video component. I was hoping to use the access plugin to control the visibility so the image would be shown when the URL is an empty string. I'll spend a little time to see if I can hook tweak this plugin but I might just roll my own from scratch since I've got limited time.

drewish’s picture

After reading through #1630820: entity_field_value is completely broken and #1601062: Field access plugin ignoring selected value I think this plugin is pretty busted and probably should not have been committed. It also throws warnings with text fields that don't expose the format.

Yuri’s picture

Is this plugin still committed and 'pretty busted' ? Or is there another more recent thread covering this issue?

merlinofchaos’s picture