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.
Hi there,
I'm setting up a community fiction/art site, and one feature I've had a devil of a time implementing is allowing users to create hierarchies of *only* their own works. Book module allows stories to be grouped hierarchically, but anyone can add a child to any parent -- can the Outline module provide limitations, so that users can only select their *own* content as the parent of each new node?
Comments
Comment #1
beginner CreditAttribution: beginner commentedYes, this is one feature that is definitely planned. It will not be part of the upcoming alpha1 release but will be part of the next releases, to come within a few weeks. The permission tables are already prepared.
Beware. The D6 version is not stable enough to use on a production site. Table definitions may change without an upgrade to be provided. If you use it, then be prepared to service the database yourself according to changes.
Comment #2
marcp CreditAttribution: marcp commentedIn the table definitions, the outline_book table has fields named book_role_perm and book_user_perm. Will there be multiple rows per book, with one row per user or role that has permission to the book?
The outline_perm table has 4 fields -- bid, perm, type, and type_id. What will these define?
It may be cleaner to leave roles out of this altogether. I understand that it would be nice to say "all users in a specific role can edit this book," but it feels like this may be abusing the role system. It would be just as easy to allow a book owner to add any amount of users as editors of the book, as long as the UI is intuitive.
Is there a specific use case for the role based permissions?
Thanks,
Marc
Comment #3
beginner CreditAttribution: beginner commentedHi Marc, thanks for your help.
I'm looking my own notes to refresh my memory about this feature.
1) All the permissions here refer to the permission of adding/removing pages from a specific book. We don't touch at all the permissions to create/edit a node. So, in the javascript callback returning the list of books for the pulldown select, only those books where the user has permission to add a page will be returned.
2) Yes, we need a permission per role. Different sites will be organized in different ways. Some sites may have many, many books with few users only for each. Other sites would have fewer books with role-based perms. Others will have a combination of both. Role-based perms is convenient and should be kept.
3) {outline_perm}:
bid: book id (i.e. nid of book cover node).
perm: [create|add|administer|...] the name of the permission to grant. My original notes list both a "create" and a "add" permission, but I am not sure now both are necessary. The "administer" perm would allow users to change the book-wide settings (TOC depth, etc.)
type: [user|role] the perm is assigned to a specific user or to a role.
type_id: either the $user->uid or $role->rid, according to type.
Thus for each book we can do a SELECT to check what perms a user has according to her uid and her role.
4) {outline_book}:
book_role_perm: boolean: whether to create a role-based permission for this book.
book_user_perm: boolean: whether to create a user-based permission for this book.
If either or both is TRUE, then we check in the {outline_perm} table for relevant perms.
Again, this is from notes written months ago. I am not sure anymore this is necessary. I think I thought about that to easy the UI, by not having a too long list of books in some sites (I'm working on a site which will have many, many books, but each having only a few users contributing to them).
Until it is clear that we need this, or on the contrary, that we won't use this ever, we can just leave the columns in place but not use them, assuming that both are set to TRUE. I.e. ignore these fields for the time being.
5) so, in answer to your first question: no, there will be only one row per book in {outline_book}, but multiple corresponding rows in {outline_perm}.
6) We don't need to implement all of this at once, in one big patch. It's ok to ignore the extra columns in {outline_book} for now and, if you wish, postpone role based perms and implement only user-based perms in a first patch as long as it is done in a way that allows us to make an incremental step towards role-based perms later.
7) In my notes, I have the concept of "personal outlines", i.e. outlines where a single user can add nodes to. All of the above require some admin intervention to set up role and user permission. I had planned to add a general admin setting (or better a role permission) allowing users to create a personal book outline without the need for an admin intervention. I.e. they would create a node (which will be their book cover: the node id will be the bid of their personal outline), they check a box saying: "use this node to create a personal outline", which in turn would automatically populate {book_perm} accordingly. Maybe an admin general setting would set how many such books can each user create (only one, zero, 2, 3... or any amount).
One use case (though not the best) would be to allow users to bookmark some pages they are interested in into their own outline.
8) All of the above suggests that nodes can be incorporated into different outlines, and each outline being browsable independently. This possibility is planned, but not ready yet at the code level. We'll have to see in which order those different features should be implemented, so that it all make sense.
9) The OP (what does OP stand for?) requested user-specific outlines where the user can only outline their own nodes (as opposed to nodes created by other users). This feature makes sense and is within the boundaries of this module. So, if this issues is to veer too much away from this feature request, we ought to start a new thread and come back to this feature later when ready.
There you are, I've presented you with a broad outline (no pun intended) of the roadmap. Let me know if you are interested in implementing one sub-set of these features.
Comment #4
marcp CreditAttribution: marcp commentedAugustin,
1) It is a great idea to defer node create/delete permissions to core and just concentrate on outline permissions.
2) Agreed that different sites will be organized in different ways. I also agree that role based permissions would be nice, but if they complicate views integration, then we should consider scrapping them.
3) {outline_perm} - Sounds good. The only reason I can think of that we'd want to separate create and add would be if we wanted some users to be able to add pages to a book but not create books themselves -- is that the way you see it? I don't know if it's worth having an extra permission for that. If "administer" allows the user to change book-wide settings, is it also required to change the order of pages, or do we need another permission for ordering? And what about removing pages? I almost think it makes sense to have just one permission -- either you can do anything to the book, or nothing.
4) {outline_book} - It feels like leaving this table here will make the initial implementation more complicated than it needs to be. We'd need to document that the table is here for future use. It may be better to add the table in at a later time when it's determined that we really need it. We can look back to this issue in the future to see the documentation, and it'll be easy to add the table back.
5) Good. Multiple rows in outline_perm -- one row for each user/book and role/book.
6) Perfect. I think we should hit the user based perms with the first patch and save the roles for later.
7) Personal outlines are just a subset of what the Outline module can do with what we've already discussed above. As you say, a user should be able to create personal outlines with a single checkbox on the book's top level node-edit form. Also, users should be able to bookmark pages into their own outlines. As far as limiting the number of books a user can own -- that seems like an add-on.
8) Allowing pages to exist in multiple books definitely raises some issues that we'll need to address at a later time.
9) We may be able to account, from the beginning, for personal outlines where the user can only add nodes that s/he owns. It's a good feature.
All of this seems to build upon the feature that some books can be fully owned by the book module. If there are no user or role permissions set via the outline module for a book, then the management of the book is left completely up to the book module. Is that the way you see this too?
We're looking forward to working on the personal outline piece shortly.
Marc
Comment #5
beginner CreditAttribution: beginner commented3) {outline_perm} We can start with one permission (say 'administer') and see if there is a need/demand for more fine-grained permissions later. What I tried to do is create a framework that can easily expanded in the future. But it's easier if we start with a subset of what's possible to do.
4) {outline_book} IS being used anyway. We need it to store the book default TOC depth and default child node type. This is something I thought a long time about it. I asked the dev list about the best practice: the choice was to add fields in {book} or store them in another table ({outline_book}). I was advised to make a separate table. Also, the main reason I initially wanted to avoid creating another table by adding fields in {book} was performance (not adding more queries). But the more I thought about it, the more I was convinced that I couldn't avoid additional queries anyway, so replicating part of {book} was no longer an issue. I hope that answers your final question. However, all of this is irrelevant to the current issue (User-specific outlines).
Comment #6
marcp CreditAttribution: marcp commentedYes, I see now that {outline_book} is definitely necessary. My own notes were focused on permissions.
Regarding {outline_book}, is the restricted_types column designed to be used to restrict the node types that can be included in an outline? How will the {outline_types} table work?
Thanks very much for working through this.
Comment #7
beginner CreditAttribution: beginner commentedAs you guessed, the following is another feature planned but not yet implemented . From my notes:
restricted_types: if == 1, then see {outline_types} for list of node types that can be added in this book.
{outline_types}
// list of book with specific node types that cannot be added elsewhere if those node type are also in the general settings,
// And list of node types that can be added to a book, if restricted_node_type == 1.
bid.
node_type.
For each book (bid), there will be as many rows as node types allowed. The site administrator is not limited by this.
Comment #8
Grayside CreditAttribution: Grayside commentedI've been trying to determine a good way to get something like a private (restricted edit & view) namespace or outline per user for personal notes. Would that be something this feature would provide, or is that another module to dig up?
Comment #9
beginner CreditAttribution: beginner commentedas noted above, outline.module does not deal with viewing permissions.
Comment #10
beginner CreditAttribution: beginner commentedI have committed a couple of other big patches, so do cvs update.
I am now ready to work on this feature.
The first question I am asking myself concerns the UI.
As noted above, the tables are ready. What we need now is add a form somewhere to fill in the values into the tables.
So, the question is:
Where to put the form? On the node edit page? On the outline tab? Somewhere else within the book/outline administration pages?
My gut feeling is that the latter would make better sense and the UI may be somewhat easier to implement.
Comment #11
Flying Drupalist CreditAttribution: Flying Drupalist commentedHi, I am glad to see that this is being worked on. This will probably give each of my users the ability to create their own stories and then add chapters to them.
Comment #12
jgraham CreditAttribution: jgraham commentedbeginner,
marcp had previously discussed us working with you on implementing some of the proposed features for outline; unfortunately due to our timeline to deliver this functionality to a client and some initial hesitation due to the extraneous text on the administration screen we went ahead and developed this functionality separately.
Please see our results here; Book Manager and here Book Copy The personal book functionality is provided via the Book Manager module, and Book Copy allows users to copy entire, or partial, books.
If you want outline to use Book Manager capabilities and need some behavior or functionality adjusted I would be interested in working in functionality that makes the module more useful.
Again I'm sorry that we were unable to initially work with you to get these features worked into the outline module, but would love to work with you via book_manager if that makes sense for your outline roadmap.
regards,
Jeff
Comment #13
Flying Drupalist CreditAttribution: Flying Drupalist commentedHi, I wonder how progress on this is going. I think you should put the form inside the book/outline administration pages?
That way administrators can select which content types are single-user only and which content types are multi-user.
Thanks!
Comment #14
beginner CreditAttribution: beginner commentedSorry for the delay. I have been side-tracked by the historic US elections!
I already a good patch but it's not yet complete. I'll do my best to release alpha2 this week end which will include that patch.
Comment #15
beginner CreditAttribution: beginner commentedJust committed a big patch which implements a lot of the above.
Comment #16
beginner CreditAttribution: beginner commentedMost of the above has been implemented in alpha2 release, including per role permissions, per user permissions and author specific books.
If I missed anything, please open a new issue.
Thank you all for your charitable support.
Comment #17
beginner CreditAttribution: beginner commentedComment #18
Flying Drupalist CreditAttribution: Flying Drupalist commentedDying to use this, but uh, don't want to break my production site. Is it really as unstable as advertise? Thanks.
Comment #19
beginner CreditAttribution: beginner commentedThings might still change, though unlikely.
Check every feature on a test website: see the handbooks to see how to replicate your website on a test platform on your own computer.
Me, I'm dying to receive everybody's charitable support, and to see more of the module's users supporting charities of their choice as a form of pay back.