access control aware tag clouds

Can you make a real patch from this? http://drupal.org/diffandatch

Thanks!
it worked for me with no visible issues.

works good for me too!

Unfortunately not included in the latest release...

I am a bit reluctant to simply add the db_rewrite_sql without extensive testing.
Problem is that the query is rather complex. And I know for certain that some access cotnrol modules, such as organic groups, have trouble rewriting complex queries.

It needs more testing with several complex access modules
Taxonomy_access_lite
Organic groups
.. fill in your own.

Bèr

Also look at http://drupal.org/node/62840, wich will probably solve this i18n issue.

I have been using db_rewrite_sql with rather more complex queries (extra (left/right) joins etc), taxonomy_acces and i18n. It never caused any problems.

I'm not using organic groups yet but i'm very much sure they work with db_rewrite_sql too to add extra clauses to the queries.

Tested and working for me with http://drupal.org/project/content_access

Better title.

It's a little odd that it uses a node-based rather than a term-based rewrite, but I suppose it makes sense as most (all?) taxonomy-based access control modules also restrict access to nodes with those tags; also a term-based rewrite would give inaccurate tag sizes by including inaccessible nodes in the count.

http://drupal.org/node/84095 Contains some changes to the caching. We need that in this patch too.

@Ber : I'm not sure if this is the kind of implode you want.

I've tested this patch with Taxonomy Access Control, works fine.
Though the cache is set per user role, so if you're using access control per user level.. the caching may not work properly. I suspect that TAC Lite falls into this category. Anybody can confirm ?

Guys, please review..

I don't know about TAC Lite, but OG's access control is per-group, not per-role.

... and many more ways of making access persmissions.
TRue: caching with Roles is far from perfect and we need to find another way.

Idea: db_rewrite_sql the query, hash it, and use that as cache-key.
If it exists, then continue, if not, then execute that SQL string.

It measn that we have to call some rather expensive calls, such as the db_rewrite and so, but at least it is flexible and allows for any type of access, yet still allow some form of caching on the most expensive part.

Bèr

Custom Pagers deal with this issue by storing the cache in the $_SESSION variables.
Perhaps this is the best solution?
db_rewrite_sql may not see it into drupal 7.

Better ideas ?

Another possibility could be to add the user id to the cache key.

Caching by UID seems like a sensible way of doing this. We would need to make sure their cache was invalidated every time their access rights changed though.

ok, for the all the people having issues with tags showing up for unpublished nodes, or tags for nodes that users should not see, you can use the tagadelic_views module to accomplish the same default block that comes with the tagadelic module, but in the filter for the view, just set what you want to filter/show by.

I use the workflow module so tagadelic views came in very handy to show only "published" articles.

Bèr Kessels, after searching the issue queue, I saw a couple duplicate posts with this issue and it's probably (at least to me) a very important issue for users not to see tags for nodes they should not see.

So maybe you can mention tagadelic_views will solve that problem in the duplicated issues.

I am not sure of the performance impact with using tagadelic_views though...anyone?

ps maybe it might also be a good idea to mention this issue on the module's page or in the readme file (tags showing up for non-published nodes etc).

I am not all too happy with the concept of caching on a parameter that *we* choose.
Tagadelic knows nothing about the module that implements the access-control, as it should be.
So we may (and by rule of law, hence *will*) make false assumptions and cache the wrong data. Resulting in people still seeing tags they should not see, or people not seeing tags that they shoud see.

I am leaning towards a method where we simply disable caching alltogether, when there is a module that implements db_rewrite_sql.

Another option could be to create the SQL, running it trough db_rewrite_sql and hashing that. This hash can be used as key for the cache.
This may, in some situations, lead to a huge amount of cache-items, but will, in general work as it does now, with the same amount of cached-entries.

Can anyone look at the latter option? And see if that gives us a nice lead?

will there be a new release soon for the 6.x branch? I really need this feature in order to be able to display language-dependant tagclouds :-(

@hctom: if you really need this, then please join the effort.
I don't need it, so I have no incentive to fix this. You seem to need it, so go ahead: and participate! And thou shalt be rewarded with Kudos as far as the eye reaches.

Closing "needs work" that has been open for a long time, without anyone working on it.

This issue has been fixed in #250818: SQL accounting for revision history and i18n.

This message as a courtesy to people looking through the issue queue. Several issues are marked as duplicates of this, and the "won't fix" status was misleading since this issue is actually fixed.