User can create page for every books
juanolle - November 28, 2008 - 10:33
| Project: | Book access |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | fixed |
Description
I have Group "gr_one", "gr_too" and "gr_three". And I have one Book ("bk_one", "bk_two" and "bk_three") for every Group.
Everyone have View access to all books, but Edit and Delete is restricted to Groups own Book.
My Problem is that everyone can Create Page to every Book. So gr_one can Create Page to bk_two but not edit or delete it.
How can I deny Create Page to others Books? So only gr_two can Create Page to bk_two?
Thanks
#1
#2
Do you mean that users can create a
pagecontent type, and then add it to the book like child page?I ask because there are two content types that have a similar name; one is page, and the other is book page: the first is created with Create content > Page, while the second is created with Create content > Book page.
#3
#4
This will happen if you have user permissions configured improperly. any permissions you enable there will be sufficient to grant privileges.
make sure you have turned off all such permissions in admin/user/permissions.
#5
That answer to the support request that can be considered fixed (won't fix status is for bug reports).
#6
Automatically closed -- issue fixed for 2 weeks with no activity.
#7
I would like to reopen this issue because I have the same problem and don't understand the answer.
I have 2 roles A and B and 2 diferent content types a_book and b_book.
Both content types are marked "Allowed book outline types".
Users of role A have the permission to create content of type a_book.
Users of role B have the permission to create content of type b_book.
Both roles have the permission "add content to book" (if they don't have this permission the book form does not show up in the content creation form).
The problem is that the users can choose to add pages to all books they have "View this book" permission, it doesn't matter if they have or not "Edit pages in this book" permission.
Thanks,
Manfred
#8
+1 for what manuweb explained. (I think the original post was explaining the same issue as well.) I've tried many ways to adjust the permissions but cannot find a solution.
This modules needs a "Create pages in this Book" permission in addition to the " View this book", "Edit pages in this book", and "Delete pages in this book".
#9
I looked deeper into this with intentions of adding a "Create pages in this Book" permission. But it seems that permission is unnecessary, the problem is arising from some bugs:
I discovered the "_book_access_restrict_options" function is buggy. It is using the $nid variable that doesn't exist in that scope.
I've attached a patch. The patch fixes the bug, so a user can only create a book page for a book on which the user has "Edit" (update) permission. However, the patch is not complete and still needs to take into account if the user has the "create new books" permission. (With this patch only the superuser can create new books.)
For my purposes, this fixed my problem. I also themed out the "Add child page" link to avoid confusion.
However, this module needs more work for full functionality. I'll post if I find time to patch it up anymore.
#10
I extended my previous patch to properly show the "Add child page" link only for books the user has edit access to. I used the hook_nodeapi, I'm not sure if that is the best way to do this. And I'm still not entirely sure on how the owners of this modules meant to use the {book_access} table.
Please review this patch and let me know if you find any issues.
#11
The 02 patch seems to work. However, if the Book Navigation block is enabled, the permissions on the individual books seem to go away.
#12
I found the patch from #10 caused fatal errors with Views RSS feeds. The problem is hook_nodeapi() returning
$nodein all cases. The documentation states that the return value should depend on$opand we should never need to return$nodeas it is passed by reference. The attached patch modifies the patch from #10 to not anything. This has fixed my RSS feed problem.#13
This is the exact patch that I was looking for. Thanks for the wonderful work.
When will this patch be committed into the module? The maintainer seems to be pretty much missing in action.
#14
I will commit the patch after I fixed some other minor issues.
<?phpif ($user->uid == 1 || user_access('administer nodes')) {
// ...
}
?>
To verify if the user is the first user is superfluous; the first user has all the permissions, and
user_access()returnsTRUEfor that user, whatever permission string it is passed to the function.#15
I think the patch in comment #10 is not correct.
The
_book_access_restrict_options()parameter$bidis really the node ID (at least that is the value the caller passes in). There is also a local variable that has the same name of the function parameter, and which overwrites it.I think that the parameter should be renamed
$nid, and the rest of the function should not be changed (apart the changes I have already done, and the change I reported in my previous comment).#17
I changed the code, and committed it in CVS.
Between 1 hour, 1 hour and 30 minutes, the new development snapshot will be available; if not, I will need to force an update by deleting the current archive.
In the next 2 days, I will create a new official release.
Thanks to everybody for the help, and the effective contribution.