How can I make it work with 4.5.0?
I have made a simple intranet using node_privacy_by_role.... and I have a vocabulary for the client and anotherone for the content type.
Now... the nodeprivacybyrole works fine, but If I play around with the url and I type (for example) taxonomy/term/1 I need to display a 403 page so the term (that it's a client name) will not be displayed.
So, how can I made it work? I read something about drupal giving view access to everyone, but I cannot find in this the right query to remove view access to everyone.
Second thing. With the module there is a taxonomy module patch, do I need to use it with drupal 4.5.0?
Any help will be muccccch appreciate!
(yes, I can remove the vocabulary clients and the problem will be solved, but I need it to better organise the data in the future)
Comments
There is a taxonomy_access.module
It's specifically for controlling access at the taxonomy level. It's not clear in your post if you have already installed it. The taxonomy.module patch is for use with the taxonomy_access.module. You will need 4.5.0 for the taxonomy_access.module to work.
Please let me know if you run into problems. It was recently patched.
it was my first solution
using taxonomy_access.module was my first solution to keep privacy between areas.
but I tested, and I could still see the nodes inside the taxonomy where the role has no read privileges.
I am using 4.5.0, regarding taxonomy_access.module I downloaded a version (not from CVS) yesterday (1st dec). Do I need to patch?
cvs
I am trying now with the latest cvs... still no success.
The user of role1 can view the term1, even if in the category permission form he hasn't view permission for that term.
maybe I haven't clear how this module work..... if the role hansn't view permission for the term1, should I have an "access denied" or just it will not show the nodes?
plus the nodes usually are in two terms... and every role has access to one of them.
Ex... all the role have view permission for the term "Reports", but just one to "Client A". Could be that a problem?
last question... is taxonomy_access enought to hide nodes, or it should be used in conjunction with node_permission_by_role?
Some answers
OK, are saying the unauthorized person is seeing the *term* but not the actual *content*? If so, where is the person seeing the term, in a forum, in a menu?
If you have installed the taxonomy.patch, you should see "access denied".
If a node is in two different categories and one is category is denied access to a user but the other permits access to the user, the user will be able to see the content.
You don't need node_permission_byrole.
so...
he sees the term if he plays around with the url. I know that it's a remote possibility that happens, but I prefere not to risk.
Unfortunately "If a node is in two different categories and one is category is denied access to a user but the other permits access to the user, the user will be able to see the content." This really complicates everything.
I am using a category for the Projects, and one for the kind of content... so while projects are restricted, the kind of content is accessible to everyone.
I could use just projects, but in the future it will be too messy to find out things :/
Thanks a lot for your help anyway
Could be changed
The behavior of the module could be changed so that if a node is in two categories with conflicting view permissions, it could take the more conserative setting and not let the user see it. Perhaps it would be good to create a new setting that would allow an administrator to decide whether a more lenient or a conservative permission handling logic should be performed. Please put in a feature request so this can be taken up for more discussion.
As far as "he sees the term if he plays around with the url" goes, that should not happen.
The user should see an "access denied" message. The taxonomy.patch is supposed to take care of that. Mine works on my site but only after tweaking the code. Other people have had the same problem. But since I can't duplicate it. Also, I have barely looked at the taxonomy.patch and I can't help much until I do. Sorry. But see comment #22 at http://drupal.org/node/13597 to see if my tweak fixes your problem.
tnx a lot...
seems good...
to begin I'll finally patch the taxonomy... after I'll try that!
patched....
I patched taxonomy.module and this is what I have achieved
I can still play around with URL... ok... not a big issue so far.
If a node is in 2 categories, where one is forbidden and one is allowed, the users without read access to both doesn't see the node. and that's excellent!
Anyway, I'll do more testing and afterwards I'll take a look at the comment#22
doh!
dunno... again it's like nothing has been installed :( I can see whatever I want and any taxonomy that I want...
yes... taxonomy.module has been patched. doh
Is module enabled?
What did you do since the time it was working?
Check to make sure module is enabled in admin | settings | taxonomy access.
yes
the module is on... installed and enabled.
I'll give you the same advice
Sorry, but I'm going to have to give you the same advice as below. Delete the modules and the entries in the term_access and node_access database tables and then reinstall the module and the patch. Make sure you download the CVS version of the module and use that. I successfully got it up and running with version 4.5.1 of Drupal. It should also work with 4.5.0.
It's a hassle, I know, but this is the kind of risk you take when using a new module that is undergoing many changes.
Please check the enabled status again
One of the things I oversaw was that the taxonomy_access.module has to be enabled in *two* different places! One is administer --> modules, the other is administer --> settings --> taxonomy access. With my previous Drupal installations I forgot the second one.
Yes
This is an unfortunate but necessary step. Someday, the Drupal core will be changed so this is no longer necessary. Until that time, the README and INSTALLATION files should probably be made more clear. I'll work on that.
this is so odd....
playing with tax_acc for the past few days, it's worked for me without being "enabled" in administer --> settings --> taxonomy access...
enabling this, everything remains the same. still getting this strange behaviour though:
http://drupal.org/node/13948
is this normal?
cheers,
kieran
Node display repetition
After an out-of-the-box installation of the taxonomy access module certain nodes are displayed more than once on summary pages for certain users. In my case the superuser isn't bothered with this *feature*, but ie. anonymous users are. The problem seems to be related to the book module. In my setup each book has its own taxonomy and the forums are categorized into a separate taxonomy. The summary page of the forums doesn't repeat its nodes, whereas the one of the books does.
Does the patch that comes with the taxonomy access module solve this problem? Does the book module need a patch too? If so, when will those patches be incorporated into the officially downloadable versions of these modules?
Please don't tell me that I have to dive into the code myself , because I don't want to end up with a personally forked Drupal to which I can't apply any official upgrades and patches anymore without loosing my own code changes. Moreover, I don't want to have to remember which patches I made for every fresh Drupal installation I intend to perform.
Download latest version of book module
Yes, this has been a problem with several modules. It is not a problem with taxonomy_access. Permissions are a new feature to Drupal and not all modules were updated in a timely fashion.
I don't know which modules have been patched to correct the problem and which modules have not. My guess is that most modules have been fixed by now. I recommend that you download the latest version of the book module and see if your problem is solved. If not, submit a bug report for the book module.
Instead, I upgraded to version 4.5.1
The book module is part of Drupal's core code and it is not available separately. Therefore I upgraded from 4.5.0 to 4.5.1. Which gave me a headache because doing so created even more problems. My home page no longer showed up. The only output I saw was a series of warnings about a parameter being of the wrong type on line 89 of modules.inc and a number of *headers already sent* messages referring to several bootstrap.inc lines.
After *null*-editing those two files and forcing my editor to save them Drupal decided that I merited seing my website again. Is this behaviour caused by Drupal's caching mechanism? If so, that should be mentioned in the file with the upgrade instructions together with a description of how to solve the issue.
Anyway, the book module in version 4.5.1 still repeats the book titles on its summary page. As you suggest I believe it is a high time I file a bug report about this.
I had this problem too - cache was the issue
I just emptied cache table with dba module and it was working fine.
Fresh install -- no cache so far
Much earlier than I expected I found some spare time last night and today to do yet another install of 4.5.1 from scratch. This time everything seems to work fine. Since up until now in this installation I didn't enable caching, I suppose you're right.
I'd like to know though what you mean by dba module before trying to enable caching this time.
dba module
Database Administration module can help you administer your database through Drupal interface. You can get it here: http://drupal.org/node/8482
Re: dba module
I prefer phpMyAdmin for database maintenance, but that would better be discussed in another thread.
Please see this patch
http://drupal.org/node/13902
Let's see if this takes care of everything.
No change
Not being able to visit my own website because of the warnings, let alone being able to execute the admin panel, I simply deleted the taxonomy_access module. After that I strictly followed and executed all the steps mentioned in node 13902 without success. When I visit my site all that is shown *again* is a bunch of warnings about modules.inc and bootstrap.inc lines.
Right now I see but one solution: reinstalling Drupal v4.5.1 from scratch and forget about books and taxonomy access. Moreover, IMO Drupal development needs a general feature stop until all the core code and all the third party modules get synchronized flawlessly. But then again, who am I ?! ;-)
True Drupal is core
True Drupal is the core modules and the database. Third party modules aren't meant to be flawless. They are basically "use at your own risk." The book module is not a third party module. I can tell you from first hand experience that it works with no errors. I also have the taxonomy_access.module installed and it is working well for me.
As far as the warnings go, you will have to post them here for anyone to help.
Books and taxonomies
Admittedly the book module is part of the core and it works. Probably I should not assign a separate taxonomy to each book that I create in order to avoid an overcrowded *Parent* dropdown list in the book page creation form.
Earlier on I filed an issue. The warnings I was writing about are included over there. But it gets worse! After a fresh install of 4.5.1, not being logged in and clicking Home yields those warnings too. Should I revert to 4.5.0 all together ?
I just got it working
Just today I did a fresh install of 4.5.1 and the taxonomay_access.module (and taxonomy.patch) with none of the problems or errors you describe. But note that I didn't use the book.module.
I looked at the line numbers the errors you got were generated on and they didn't seem to match my 4.5.1 version. Sorry, I don't know what else to tell you except maybe delete everything again and give it another shot.
Another shot by the end of the week
Okay, I'll delete everything once again and give it another shot. However, I'll only have some time to perform that experiment near the end of the week. I'll come back here and report about it. Probably next weekend.
Thank you for assisting me so far.
Successfull installation so far
Much earlier than I expected I found some spare time yesterday evening and today to perform yet another 4.5.1 install from scratch. It all works now without repetitions and without warnings or errors. As I replied higher up in this thread, I found out however that with previous installations of taxonomy_access I had overseen the fact that this module needs to be enabled in *two* different places.
Moreover, I carefully avoided to enable any internal Drupal caching for this installation. Another reply in this thread confirms that caching is one of the causes for the problems we are discussing here.
Another feature I didn't reuse so far is defining extra roles for finer grained access control. According to information elsewhere in these forums overlapping role permissions can cause some duplication too.
Also, by reading lots of posts in these forums, I came to the insight that a Drupal book doesn't need a taxonomy of its own to function. On the contrary. By itself a book is already a way of organizing nodes. Implementing a taxonomy on top of every book is merely an overkill that probably (partially) causes the repetition of titles.
In fact, a taxonomy not being needed in conjunction with books, I wonder whether I actually need the taxonomy_access module or not ? I did enable the forum module, but so far I could not work out if taxonomy_access will allow me to define which users have write access to which forum terms. I presume that the term_access module is meant to handle that problem. However, its description clearly states that it is written for 4.4.0 and that it still has its problems. For the time being I won't take the risc of ruining my working installation by experementing with an unstable module.
That is pretty much it for now. I hope all this information helps others somehow to overcome these setup problems too.
Thank you all for your help. I very much appreciate it.
The important step
I don't recall seeing any instruction to clear the cache table. I'm making note of it for my upcoming upgrade, but that should be a clear step in the upgrade installation instructions. (Very very very easy using phpMyAdmin.) I'm much relieved that this scary scenario can be avoided.
--
mediagirl.org