the attached patch is a flag Ops field handler for generic entities.

it extends views_handler_field_entity and implements functionality from flag_handler_field_entity_ops and flag_handler_relationship_content.

there are some @todo markers for code duplication which would require refactoring flag_handler_relationship_content.

maybe related to, but not depending on #1035410: Flag any entity and #1315850: Add support for Entity API properties

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dasjo’s picture

Status: Active » Needs review
mh86’s picture

Status: Needs review » Needs work
+++ b/includes/flag_handler_field_entity_ops.inc
@@ -0,0 +1,115 @@
+class recruiter_flag_search_api_handler_field_ops extends views_handler_field_entity {

really? ;)

dasjo’s picture

Status: Needs work » Needs review
FileSize
3.98 KB

sorry :) unstaged changes.
this one should be better

dasjo’s picture

with all changes

loganfsmyth’s picture

Just submitted a patch over here so you know. #1362704: Remove hook_views_handlers and fix API version

* You use "$content_type" in options_form, but it doesn't look like it is defined anywhere?
* Seems a bit odd to replace the entire form with the error instead of just replacing the 'flag' element.
* What is the benefit of this currently if it is only attached to nodes? Doesn't it just duplicate the views support that is already there?

dasjo’s picture

hi loganfsmyth,

thanks, i will look into your suggestions.

regarding

* What is the benefit of this currently if it is only attached to nodes? Doesn't it just duplicate the views support that is already there?

the patch allows to use flag in search api views for example.
i'm not an expert, so i would be asking if we can attach it to other entities as well?

jaxxham’s picture

Hi, I'm getting:

Configure field: Broken/missing handler: The handler for this item is broken or missing and cannot be used. If a module provided the handler and was disabled, re-enabling the module may restore it. Otherwise, you should probably delete this item.

In views. Any ideas?

Thanks.

joachim’s picture

Status: Needs review » Needs work

Sounds like the patch needs further work.

joachim’s picture

Status: Needs work » Postponed (maintainer needs more info)
+++ b/includes/flag.views.inc
@@ -26,6 +26,9 @@ function flag_views_handlers() {
+      'flag_handler_field_entity_ops' => array(
+        'parent' => 'views_handler_field_entity',
+      ),

This hook doesn't exist in D7.

And more generally, I don't really get the point of this patch and this issue.

With #1035410: Flag any entity, I can make a view of any entity type and get a flag link on it with the relationship. Marking as postponed until someone explains to me why we need this.

mh86’s picture

Status: Postponed (maintainer needs more info) » Needs work

The idea of this patch is to display the flag/unflag link on any kind of view, in particular on Search API views (and the Search API views integration uses the generic Entity API views tables).

Maybe we've missed something, and it's already possible with the existing code. Furthermore this patch just exposes the link for the generic node table (views_entity_node) and misses the other possible entity types. And maybe just adding an Entity API property for flag links is easier / more useful and does the job for views as well.

joachim’s picture

Status: Needs work » Closed (won't fix)

I'm going to mark this as wontfix.

If I've misunderstood what this issue is about and what the patch does, please reopen and explain it :)

mh86’s picture

Title: Add views handler for flag entity links » Independent views query backend flag links
Version: 7.x-2.x-dev » 7.x-3.x-dev
Component: Flag core » Views integration
Status: Closed (won't fix) » Needs review
FileSize
5.23 KB

Re-opening this issue with an updated patch for the new branch.

But first of all I'll try to explain it in a better way: Views has the ability of different query backends. By default it comes with the database backend, that of course supports all entity types. The Search API (and maybe others) have their own backend and can't use database specific fields. So at the moment I can't display a flag link field on a Search API listing.
Views already has a solution for that, as it includes generic 'views_entity_' . $entity_type base tables, that can be used by any backend and do not rely on database queries, e.g. this is used for the node edit links.

Now this patch adds a flag handler to the generic tables. Thus is can be used with Search API and even the Database backend, which, unfortunately, duplicates the functionality with the existing flag handler.
The patch might need some further tweaking (code reuse, comments), but let's first clarify how we can get something like this into the flag module.

mh86’s picture

Updated patch that fixes php warnings with empty views results.

joachim’s picture

I appreciate the work you're doing on this, and I apologize for the delay in reviewing.

I need to take some time to properly get my head round this different query backend malarkey -- any links you can post to blog posts / tutorials / other gentle introductions would be much appreciated.

kaizerking’s picture

@#13 this patch could not be applied

mh86’s picture

The original Views issue for generic entity fields is here: #1172970: provide a unified way to retrieve result entities

I see the current patch only as a starting point on how the code could look like, but I'm not really happy with it yet. It duplicates the flagging handler for the database backend and there is some code duplication. Replacing the existing database flag op handler with this code isn't a good idea either, as it can't join to the flagging table and needs to query each entity (if it's flagged) separately, which will be less performant.

@kaizerking: are you using the latest 3.x dev snapshot?

kaizerking’s picture

yes, I have netbeans git cloned

joachim’s picture

Sorry, that issue is still Greek to me. Can you give me an example of how this is actually used?

Also, AFAIK netbeans is rubbish at applying patches.

mh86’s picture

yep, use Search API with Views and a table listing and try to display the flag link in a column

joachim’s picture

Ok, but it's more this bit that I need explaining in words of one syllable or less:

+++ b/includes/views/flag.views.inc
@@ -200,6 +200,17 @@ function flag_views_data_alter(&$data) {
+      // Flag links based on the generic 'views_entity_' . $entity_type tables
+      // that can be used by any query backend.

I still have no idea why views has a load of 'views_entity_FOO' tables, or what a query backend is.

Sorry to be dense.

mh86’s picture

I'm not a Views expert, but I'll try to explain it:
Views allows to have different types of query backends, but only implements the database backend. Other modules may implement different ones, like the Search API in order to connect to different sources, like Apache Solr.
The way field data values are retrieved is usually different (sql selects in the database backend, entity loads + field values extraction in Search API, etc...). So actually, you would have to re-implement your field handler for each backend type.
Some of the fields are pretty simple, like a node edit link, and can be made reusable across the backends. Instead of directly accessing the node id from the sql result, the full entity is loaded in a generic way and used for constructing the link.
For example, if you look at node.views.inc, you'll find following code:

  $data['node']['edit_node']['moved to'] = array('views_entity_node', 'edit_node');
  $data['views_entity_node']['edit_node'] = array(
    'field' => array(
      'title' => t('Edit link'),
      'help' => t('Provide a simple link to edit the content.'),
      'handler' => 'views_handler_field_node_link_edit',
    ),
  );

The first line just tells that the old database specific implementation has been moved to the generic entity table (views_entity_[entity type]) and fields from this table can be used with any backend.

While I see that the current flag link database specific implementation has some advantages, it is still a bit comparable to the node edit link use case.

I have no idea if any of this information helps ;-)

joachim’s picture

Yes, that's a huge help thank you!

I actually get it now. (And it seems rather crazy to me, but that's out of the scope of this issue!)

> I see the current patch only as a starting point on how the code could look like, but I'm not really happy with it yet

Does your patch still need more work?

mh86’s picture

I was taking a look at the latest patch again: it might need some documentation and variable naming improvements, but the thing that bothers me is the duplication of flag handler for the database backend.

With this patch you would have two possibilities for adding a flag link: first you can use the new "Content: Flag links for entities" handler, and second you can add the flag relation and the according flag link handler. Having both will confuse people, and I don't know yet, how to best solve it (not sure if a better naming of the handlers will be enough)

bennos’s picture

using flag relation is the typical way in flag module. My vote for this way. It woul be more consistantly

joachim’s picture

Status: Needs review » Needs work

In light of the above two comments I'm going to set this back to CNW. I'm not entirely sure what is still needed here, but it looks like this patch has some more development to go before being stable :)

mvc’s picture

mh86, thanks very much -- this code works beautifully for me using a view with a search api backend.

it seems like the only problem here is a usability issue in the case of the database backend. is it possible to simply make your code not run for the default database backend?

AllanTheDream’s picture

Hello All,

The patch in comment #13 works fine at adding the flag links as fields in a Search Index view(a view of type search index) - I have applied the patch to the flag module, updated the database, and the flag links field appeared in the list of fields in the view which wasn't the case before applying the patch. The trouble am getting with this is that the patch seems to have changed a number of things in the database and it has messed up some configuration or code in the flag module, let me get you up to speed on what I did and this is before I applied the patch;

  1. I created a flag;
    • Flag type - Nodes
    • flag access (flag, unflag) - authenticated user
    • Bundles - I added it to a content type
    • Flag access by content authorship - No additional restrictions
    • Display Options - Display link on node teaser, Display link on node page
    • LInk type - JavaScript toggle
  2. I then installed the Rules project, incidentally I wanted a user, when logged in, to flag only a single node of this node-type at a time. I had to trim the flag, I created a Rule;
    • Name - .........
    • Tags - ...........
    • React on event - A node has been flagged under, "name of flag"
    • I then added an action to the rule:
      • Event - Trim a flag
      • on the resultant page I checked the flag I wanted to trim, Data selector - flagging_user, and I fixed the flag queue size value to 1 since I wanted a single node flagged at a time
  3. The Flag and the Rule seemed to work fine, the user could only flag a single node of this node type at a time.

  4. I then created a search index of item type node, I then created a view using the search index - I added fields and right about now is when I got to know that I couldn't add the flag links as a field in this view.
  5. I looked around the internet and Drupal.org , I tried a few patches but they couldn't deliver the flag links as a field on a search index view. I then landed on this, I tried the patch (I had to first download flag-3.x-dev, I applied the patch to flag-3.x-dev and I updated the database)and Voila the flag links appeared and I added the flag links to the view display as a field.
  6. When I applied the patch it changed some configuration in the flags I already had on the website, and it also renamed some tables or columns in the database(it made changes in the database)
  7. I hadn't noticed this, right after applying the patch and updating the database, but I have come to find that I can have more than one node flagged at a time (the initial behaviour was that a user can only have a single node flagged at a time) and I cannot unflag a node using the unflag link, when the unflag link is clicked an AJAX error is thrown up -
    An HTTP error 500 occurred.
    http://localhost/easymappr/flag/unflag/default_preset/2?destination=node/3&token=F7womPmN599o72GdXkN0LSrYZzxaV7fguLvSFkYO0HU 

    - default_preset is the flag's machine name

My question is, is this patch messing up the flag code and the database that the flag can't be trimmed anymore, and I can't unflag? Please help me out, and give me some insight into this.

robinvdvleuten’s picture

It works correctly in combination with the Search API and Views. Thanks!

zilla’s picture

is this almost RTBC, or are the issues in #27 above still persistent?

pinkonomy’s picture

I tried the patch on #13 on a search api view . It works fine,the flag is appearing as a field in the View. (The view is of type Solr index).
But this field is of type "Content" ,not "indexed node" . Is this fine or should also be indexed?
thanks

pinkonomy’s picture

@robinvdvleuten Which patch did you test?

pinkonomy’s picture

#13 doesn't work for me :(
Anyone help on this please?

EDIT:After trying #13 I can see a Flag field in the view ,but its not indexed.Is this correct or should be indexed?

pinkonomy’s picture

Also,how can I create a view search api with only flagged content?This needs a reference of the flag correct?Does this need another patch?

mas0h’s picture

Issue summary: View changes

Any update on this?

campbdy’s picture

Subscribing

Would like to be able to add relationship to Search API view to get flags for the current user, i.e. Flags: compare_bookmarks (by current user), as you can in 'normal' views.

joachim’s picture

There's no need to subscribe to issues like that any more: just use the 'follow' button.

And for general information: this issue is not going to be advanced by the current maintainers, as it involves areas that are out of our expertise (well, mine at least). The only way this will move forward is if people who need this feature work on it and create a patch which is reviewed by other users who need this feature.

marcoka’s picture

applied the patch. the question now is where can i add the flag link. i created a view using search api and added indexed fields. if i go "add fields" i can see no flag link i only see the fields indexed by search api.

edit: this will only work if the NODE ID is indexed. Otherwise no link field appears :)
if i select it the i get "missing plugin error"

p.s this is a really useful idea.

khiminrm’s picture

patch from #13 works for me (Flag 7.x-3.5)

dimapanin’s picture

@mh86 thank you, patch from #13 post works (Flag 7.x-3.5).

pinkonomy’s picture

Patch from #13 works,however when added in a view,it says : Content: Flag link for entities
Is this fine or should this field be indexed like the other fields?
thanks

7thkey’s picture

Patch #13 works for me using the latest dev version.
Thanks!!

Nkendall’s picture

Hey everyone, the update on 10/18/2015 seems to have broken patch number 13. This is way above my head, but the issue seems to be that the code at line 200 in includes/views/flag.views.inc has changed the data alter function. I'm not sure how to modify the new function, but from my novice's eyes that's all I can figure...

criscom’s picture

Same here, update to Flag 7.x-3.7 breaks my site (WSOD).

PHP Fatal error: require_once(): Failed opening required '/var/www/mysite/sites/all/modules/flag/includes/views/flag_handler_field_entity_ops.inc' (include_path='.:/usr/share/pear:/usr/share/php') in /var/www/mysite/includes/bootstrap.inc on line 3186

ibuildit’s picture

Confirming it does not work with 3.7 but works with 3.6

aseabrook’s picture

Ditto. Can we get an updated patch?

monstrfolk’s picture

This worked on 3.7 dev for me.

nicxvan’s picture

This allows me to add the flag / unflag link, does anyone have any guidance to how to get a relationship or sort from this? I need to sort the results based on which items a user flagged.

joachim’s picture

> Confirming it does not work with 3.7 but works with 3.6

The patch applies on dev at least:

patching file flag.info
Hunk #1 succeeded at 27 (offset 3 lines).
patching file includes/views/flag.views.inc
Hunk #1 succeeded at 243 (offset 43 lines).

Whether it actually works or not I don't know.

> This worked on 3.7 dev for me.

There's no such thing... 3.7 is a fixed release. Dev is the latest from git.

liland’s picture

Patch #13 didnt work now even on Flag v3.5
I can see new field in Views "Flag link for entities", but when i add this to my View i get error - handler is broken or missing.

Node ID is indexed (comment #37)

If someone can help - I will be grateful.

oldspot’s picture

Just applied patch #13 to 3.7 and all went well:

patching file flag.info
Hunk #1 succeeded at 27 with fuzz 2 (offset 3 lines).
patching file includes/views/flag.views.inc
Hunk #1 succeeded at 243 (offset 43 lines).

Cleared caches and the "Flag link for entities" appeared in my search api view. Thanks.

Goodmood’s picture

Hi @liland.

I had the same problem after applying of the #13 patch.

So I had a new field "Flag link for entities" in my views, but after adding it received "broken handler".

I'm using some contrib profile on website with included organic groups module. After checking my VCS I found, that new handler from patch #13 was placed in wrong directory (og module instead of flag). After replacing file I found that flag field working well for me.
Probably you have the same problem?

Best regards.

ishan.dikshit’s picture

Anyone facing any issues with flag 3.9? It doesn't work for me.

criscom’s picture

The update 7.x-3.9 only worked with the patch in #13. We haven't edited the views yet but the field has "Flag link for entities". So as of now all good.

joachim’s picture

Could some of the apparently large number of people using this patch actually take the time to reroll it and review it? Contribute back please, as well as benefiting from other people's work!

Marcus 78’s picture

Workaround

Use https://www.drupal.org/project/views_field_view
Use node id as a field in index
Create a view with contextual filter on node id, relations to the flag that you want. Lets call it flagview
Add the flagview inside your search view and use the node id a the contextual filter on the flagview

All modules, no code

Drawbacks, might be a bit slow but it worked for my project

bisonbleu’s picture

Needed to apply the patch in #13 to a fresh version of flag (7.x-3.9). Re-rolled the patch against 7.x-3.x.

destinationsound’s picture

Tested #56 on the latest version and it works fine, however, it doesn't address the Filter or Sort Criteria integration. It would be great to have Flag fully integrate with Search API Views including the various criteria options present in a regular view integration.

Any idea how difficult it would be to add Filter and Sort Criteria options to this patch?

hongqing’s picture

Is there a patch for Drupal 9? Thanks.