Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Robert DeArmond’s picture

Subscribing. Any word on this integration?

xjm’s picture

I personally probably won't get to this until I have a stable alpha. However, patches welcome!

iv’s picture

What's missing/not working? (I'm using Views 7.x-3.0-rc1 and TAC here, and haven't seen major problems....)

xjm’s picture

#3: In D6, someone provided filters to filter views by TAC grants (#786360: Add view filters for each permission). E.g., to create a view of all the nodes a certain role had access to. They didn't use TAC's full grant logic, though (see #901938: Views filters exclude nodes with grants inherited from global or vocabulary defaults).

I've removed them for the time being in the hope that Views 3 will make it easier to add these filters using TAC's logic, or that node access filters in general will be more fully featured (making TAC filters unnecessary).

xjm’s picture

Title: Provide Views 7.x-3.x support » Provide Views 7.x-3.x filters for each permission
xjm’s picture

roderik’s picture

Uploading to this issue without a status change: a patch that implements checking for list (i.e. View Tag) access on terms.

This is not a port of the D6 modules. It doesn't join the node_access table into the query. Instead, it joins the taxonomy_index table, and filters those on a list of tids which the current user has access to. Those tids are retrieved before the query is executed.

For my specific use case (a large forum site where Taxonomy Access is used as the only node_access module, meaning that nodes tagged with a certain term are either 'all accessible' or 'all inaccessible'), this yielded leaner database queries than using 'real' Node Access mechanisms.

Why only 'list' access?
Because I found an easy function taxonomy_access_user_list_terms() which can return the terms which I need, but only for 'list'. 'create (Add Tag)' would also be possible in this easy way... but I don't immediately see a function to return a list of tids which the user has View/Update/Delete access to. And that probably makes sense -- but I admit to not having enough overview of node access or Taxonomy Access internals, to judge that.

So this is just a 'hit and run' post. I didn't see another place to contribute this. Works For Me, Ignore If Not Good Enough.

xjm’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, taxonomy_access-viewsd7-filter-list.patch, failed testing.

roderik’s picture

Status: Needs work » Needs review
FileSize
3.88 KB

Hm. Noise in patch. 'patch' works OK (with a little fuzz), but 'git apply --check' complained.

Anyway, the above version breaks with views >=3.2. This one should work.

Status: Needs review » Needs work

The last submitted patch, 1097806-10.patch, failed testing.

roderik’s picture

Status: Needs work » Needs review
FileSize
3.78 KB

Heh. I think I get it. It's the context area in the .info file where it borks.

The patch applies against HEAD. I rolled the patch against a downloaded 7.x-1.x-dev -- which includes the "Information added by drupal.org packaging script".

a little hand editing of the patch might work. Let's see.

xjm’s picture

This looks great! I'm glad to see the TAC API being used correctly, too. :) One remark:

+++ b/includes/taxonomy_access_handler_filter_list_terms.incundefined
@@ -0,0 +1,56 @@
+ * This can replace node_access filtering (which is generally slower)

"View Tag" does not actually use the node access at all; it is just a query alter.

roderik’s picture

Indeed, "View Tag" does not use node access. That's why you can use it as a replacement for node access, in specific cases.

To give a practical example of what I said in #7 / the code comments: I maintain a really big forum website, which uses TAC to implement access control for forums. The (Advanced Forum) views therefore join the node_access tables to the SQL, since these views are 'node based'.
But if I set "Disable SQL rewriting" in the view and add this "View Tag" filter instead, I get the same result with a much less expensive query.

...The comment may not be generic enough to cover use cases (or be self explanatory); I can't really judge that. Please adjust to your liking, if you want to take this into the module.

xjm’s picture

To give a practical example of what I said in #7 / the code comments: I maintain a really big forum website, which uses TAC to implement access control for forums. The (Advanced Forum) views therefore join the node_access tables to the SQL, since these views are 'node based'.
But if I set "Disable SQL rewriting" in the view and add this "View Tag" filter instead, I get the same result with a much less expensive query.

This is very interesting, quite clever, and very potentially confusing. :) I'll ruminate a little. Overall, though, I think this patch is great.

brianbrarian’s picture

Thanks, @roderik. I manually applied the patch from #12 to TAC 7.x-1.x-dev, and it works wonderfully for me.

Though it took me a while to catch on that I needed to check "Disable SQL rewriting" in my view's advanced settings. That's what I get for not reading the thread closely enough the first time.

gittosj’s picture

Just tried to apply this against latest dev and the changes to info are failing - easy to manually apply bu needs to be re-rolled

astutonet’s picture

Hi

Maybe my problem is related to this issue. I use the module Taxonomy View Mode (TVM) to display teasers of some terms in a site.

The TVM module facilitates the display of taxonomy terms through Views.

It happens that I need to restrict the display of the content of this site for anonymous users and all the content I need to restrict has pages generated by TVM module.

Well, I applied the restriction to these terms to restricting part of my content to anonymous users, but a 404 error page is displayed when this type of user clicks on the links to these pages. Even disabling the SQL rewriting. Before I restrict the content, everything worked perfectly.

I tried solving the problem by applying the patch in #12, even realizing that it needs review, and the error persists.

In pages generated by nodes or other modules, I managed to achieve the effect I wanted.

I'm using the following modules:

- Views
- Taxonomy Access Control
- TAC 403 Redirect
- Other related modules

It is possible to extend the functionality of this patch to the TVM module?

Tks.

jenlampton’s picture

@astutonet this issue is about adding views filters for the TAC module.

If you are getting an unrelated error, you should create a new issue and explain in detail the problem you are having there. You can link to this issue and state that you tried this patch thinking it might help, but please don't take over this issue to talk about some other problem :)

Patch review: The filter in this patch does not affect my view in any way. The results are unchanged. :(

I am user in the role 'group 1' (no other roles, other than authenticated, and not user 1).
Role 'group 1' permissions: none.
Role 'authenticated' permissions: only 'View published content '
UPDATE: I also tried removing this permission. Result unchanged.

TAC settings for 'group 1' role: I/A/A. Add tag:yes. View tag: yes.
I have 4 pieces of content, 2 with the term 'group 1' (no other terms).

My view shows the node title, taxonomy term, and edit link (fields) for all published content on my site.
I checked the "Disable SQL rewriting" box under "Query settings".
I added a (term) relationship from content -> term.
I then added this filter, using the (term) relationship.

View without this filter shows 4 pieces of content, SQL:

SELECT node.title AS node_title, node.nid AS nid
FROM 
{node} node
LEFT JOIN {taxonomy_index} taxonomy_index ON node.nid = taxonomy_index.nid
LEFT JOIN {taxonomy_term_data} taxonomy_term_data_node ON taxonomy_index.tid = taxonomy_term_data_node.tid
WHERE (( (node.status = '1') ))
LIMIT 10 OFFSET 0

View with this filter still shows 4 pieces of content. SQL (looks the same to me)

SELECT node.title AS node_title, node.nid AS nid
FROM 
{node} node
LEFT JOIN {taxonomy_index} taxonomy_index ON node.nid = taxonomy_index.nid
LEFT JOIN {taxonomy_term_data} taxonomy_term_data_node ON taxonomy_index.tid = taxonomy_term_data_node.tid
WHERE (( (node.status = '1') ))
LIMIT 10 OFFSET 0

I'm not that familiar with TAC so I may be doing something wrong with my set-up, would love some tips as to how this is supposed to work.