Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Port TAC's Views integration to D7. See also: #901938: Views filters exclude nodes with grants inherited from global or vocabulary defaults.
Comment | File | Size | Author |
---|---|---|---|
#12 | 1097806-12.patch | 3.78 KB | roderik |
#10 | 1097806-10.patch | 3.88 KB | roderik |
#7 | taxonomy_access-viewsd7-filter-list.patch | 3.93 KB | roderik |
Comments
Comment #1
Robert DeArmond CreditAttribution: Robert DeArmond commentedSubscribing. Any word on this integration?
Comment #2
xjmI personally probably won't get to this until I have a stable alpha. However, patches welcome!
Comment #3
iv CreditAttribution: iv commentedWhat's missing/not working? (I'm using Views 7.x-3.0-rc1 and TAC here, and haven't seen major problems....)
Comment #4
xjm#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).
Comment #5
xjmComment #6
xjmIn a way, this is a dup. of #620392: Allow edit and delete access check in "Node Access: Access" filter.
Comment #7
roderikUploading 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 thetaxonomy_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.
Comment #8
xjmComment #10
roderikHm. 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.
Comment #12
roderikHeh. 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.
Comment #13
xjmThis looks great! I'm glad to see the TAC API being used correctly, too. :) One remark:
"View Tag" does not actually use the node access at all; it is just a query alter.
Comment #14
roderikIndeed, "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.
Comment #15
xjmThis is very interesting, quite clever, and very potentially confusing. :) I'll ruminate a little. Overall, though, I think this patch is great.
Comment #16
brianbrarian CreditAttribution: brianbrarian commentedThanks, @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.
Comment #17
gittosj CreditAttribution: gittosj commentedJust tried to apply this against latest dev and the changes to info are failing - easy to manually apply bu needs to be re-rolled
Comment #18
astutonetHi
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.
Comment #19
jenlampton@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:
View with this filter still shows 4 pieces of content. SQL (looks the same to me)
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.