- Development - lists.drupal.org

[drupal-devel] [bug] Incorrect access checking for username auto completion
by Dries 04 Sep '05

04 Sep '05

Issue status update for http://drupal.org/node/24617 Post a follow up: http://drupal.org/project/comments/add/24617 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: drumm Updated by: Dries -Status: patch (ready to be committed) +Status: patch (code needs work) The problem with Thox' patch is that it doesn't work when editing comments; some people might have 'adminster comments' permission, but not 'administer nodes' permission. The problem with Morbus' patch is that everyone can access all usernames. (Example: http://nhpr.org/user/autocomplete/a) Dries Previous comments: ------------------------------------------------------------------------ Thu, 09 Jun 2005 00:36:55 +0000 : drumm The auto completion for user name on node edit pages checks user_access('administer users') when it should be something more like node_access($node, 'edit'). ------------------------------------------------------------------------ Fri, 10 Jun 2005 15:32:58 +0000 : Thox -1 The current "Authored by" field is only for users "administer nodes" permission. ------------------------------------------------------------------------ Fri, 10 Jun 2005 15:35:53 +0000 : Thox Whoops, administer nodes != administer users. This makes things different. The true permission should be administer nodes... which almost suggests that the autocomplete function should be part of node.module, not user.module. It depends where else the autocomplete is used in the future. ------------------------------------------------------------------------ Fri, 10 Jun 2005 15:57:50 +0000 : killes(a)www.drop.org I think the function should stay in user.module, but node.module should get a menu callback that utilizes it. This is not a problem as user.module is a required module. ------------------------------------------------------------------------ Fri, 10 Jun 2005 19:40:57 +0000 : Thox Attachment: http://drupal.org/files/issues/access.patch (1.55 KB) Attached patch moves the menu entry from user.module into node.module and fixes the permission check. ------------------------------------------------------------------------ Tue, 05 Jul 2005 18:24:15 +0000 : Dries Say we wanted to make the Author-field on "edit comment" pages editable. I think the permissions would clash, and you'd be able to by-pass permissions if you have access to at least one (because they'd all share the same callback). So, I don't think this solution is sufficiently generic and possibly insecure. Not? ------------------------------------------------------------------------ Tue, 05 Jul 2005 18:55:17 +0000 : moshe weitzman I think some are compounding two separate idea. In my mind, the username autocomplete callback needs a very minimal permission like 'view user profile'. And that callback belongs in user.module. The decision about showing the author field and the responsibility for validating its contents belong to node.module and comment.module (in Dries' example). ------------------------------------------------------------------------ Thu, 07 Jul 2005 08:31:08 +0000 : Thox If the menu item stays in user.module and the permission changed to 'access user profiles', then any users that are 'administer nodes' but not 'access user profiles' would get errors trying to use the autocomplete. The following would work, but I'm not sure if it's the right way to go: <?php 'access' => user_access('access user profiles') || user_access('administer nodes') ?> I think the 'access user profiles' permission is best to use, possibly even going far enough to change the autocomplete field to a plain text field if the user doesn't have the permission. ------------------------------------------------------------------------ Wed, 24 Aug 2005 19:21:39 +0000 : Morbus Iff I'm not entirely sure what Dries is talking about in #5. However, I tend to think that "access user profiles" is the right way to go - I've been testing changing $admin_access to $view_access on NHPR.org, and it seems to work fine. By itself, being able to access those URLs isn't any sort of security concern - the places that depend on it for editing (such as 'administer nodes') is controlled by a much stronger permission. Thox's comment in #7 would be a problem, true, but I'm trying to figure out when someone would have 'administer nodes' permissions without having the ability to view a user profile (if they're able to edit the node of someone else, shouldn't they know as much public information about that user as possible?). ------------------------------------------------------------------------ Thu, 01 Sep 2005 18:13:47 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_24617_autocompleteperms.patch (793 bytes) This is the currently running code I have over on NHPR.org.

1 0

[drupal-devel] [bug] function format_date uses gmdate() incorrectly
by thehunmonkgroup 04 Sep '05

04 Sep '05

Issue status update for http://drupal.org/node/29681 Post a follow up: http://drupal.org/project/comments/add/29681 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch (code needs review) i'm fairly certain that my logic is correct here. the php doc on gmdate() is not totally clear, but i think that if you read it over closely, you'll see that it's the other way around--gmdate() is actually the one that adjusts the timestamp passed. i would recommend writing some short scripts to test out how gmdate() and date() actually operate(that's what i had to do!)--i think you'll see that what happens is gmdate() takes the timestamp passed, applies the server timezone offset, and returns the (formatted) result as GMT. that's what my tests have shown, and for the format_date function, this operation is incorrect--the goal of the function is to simply make the timestamp passed into a human-readable date. no adjustment is necessary. thehunmonkgroup Previous comments: ------------------------------------------------------------------------ Thu, 25 Aug 2005 22:04:51 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/format_date.patch (817 bytes) function format_date in common.inc is using gmdate() incorrectly. the function is trying to format a local timestamp, and GMT conversion is incorrect in this case. date() should be used instead. bug also exists in 4.6, and this patch should apply there, too. haven't checked the earlier versions of drupal... ------------------------------------------------------------------------ Sat, 27 Aug 2005 04:47:39 +0000 : thehunmonkgroup switching to patch status ------------------------------------------------------------------------ Sat, 03 Sep 2005 23:05:37 +0000 : clydefrog Are you sure about the logic here? I've tried to fix timezone issues before, and I always get confused. My reading of the documentation makes me think your patch is wrong: If the timestamp has already been converted to a localized time, then gmdate() should be used because gmdate() does no timezone adjustments (it does not care what PHP's timezone settings are). Using date() is incorrect because it does care what PHP's timezone settings are.

1 0

[drupal-devel] Disaster Relief: Projects we need help with
by Kieran Lal 04 Sep '05

04 Sep '05

Hello, there are several efforts ongoing to provide technical assistance to the Relief Effort. For a general overview, read David Geilhufe blog here: http://blog.social-source.com We have created a Katrina development list which you can subscribe to if you are reading this from a forwarded email: katrinadev- subscribe(a)civicspacelabs.org I see several efforts going on. Let me list them in order of priority as I understand them and then you all can correct me. 1)schema/dictionary for missing person data. http://zesty.ca/ katrina/- Lead Ping Yee and Jon Plax 2)Get an RSS standard. http://www.afallstardjs.com/test.xml -Jon Plax 3)Identify data sources: http://del.icio.us/tag/peoplefinder. Volunteers needed to move this list: http://neworleansnetwork.org/ node/22 to the peoplefinder tag. John Lebowsky and Ethan Zuckerman. http://www.omidyar.net/group/katrinarefugee/news/0/ 4)We need data: David NewBerger:thegeekguy@gmail.com and Tony Chang: tony(a)ponderer.org are working on crawlers. Crawlers should post their efforts here: http://www.omidyar.net/group/katrinarefugee/news/2/ 5)Accomodation matcher. Michael Haggerty is coding away on modifying event finder to help. I have posted a accommodation spec here: http://neworleansnetwork.org/node/29 6)Remotely acquired data can be posted over HTTP POST to the New Orleans Network CiviCRM contact database. Dave Greenberg. http:// neworleansnetwork.org/node/30 7)http://neworleansnetwork.org a Drupal/CivicSpace site with CiviCRM customized as a people finder application. 8)Chris Holland and Josh Kleinpeter are looking for a dedicated crawler that they can point at a list of people sites. If you have a search appliance you can donate some cycles to please contact them. If you can please post to the katrinadev list and let us know what you can do. Cheers, Kieran

1 0

[drupal-devel] [bug] function format_date uses gmdate() incorrectly
by clydefrog 04 Sep '05

04 Sep '05

Issue status update for http://drupal.org/node/29681 Post a follow up: http://drupal.org/project/comments/add/29681 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: clydefrog Status: patch (code needs review) Are you sure about the logic here? I've tried to fix timezone issues before, and I always get confused. My reading of the documentation makes me think your patch is wrong: If the timestamp has already been converted to a localized time, then gmdate() should be used because gmdate() does no timezone adjustments (it does not care what PHP's timezone settings are). Using date() is incorrect because it does care what PHP's timezone settings are. clydefrog Previous comments: ------------------------------------------------------------------------ Thu, 25 Aug 2005 22:04:51 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/format_date.patch (817 bytes) function format_date in common.inc is using gmdate() incorrectly. the function is trying to format a local timestamp, and GMT conversion is incorrect in this case. date() should be used instead. bug also exists in 4.6, and this patch should apply there, too. haven't checked the earlier versions of drupal... ------------------------------------------------------------------------ Sat, 27 Aug 2005 04:47:39 +0000 : thehunmonkgroup switching to patch status

1 0

[drupal-devel] [bug] Can't post comments when using PHP5
by michaelsb 04 Sep '05

04 Sep '05

Issue status update for http://drupal.org/node/30354 Post a follow up: http://drupal.org/project/comments/add/30354 Project: Drupal Version: cvs Component: comment.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: michaelsb Updated by: michaelsb Status: patch (code needs review) Attachment: http://drupal.org/files/issues/comment_15.patch (800 bytes) I get the below warning and form error when trying to add comments to any node (story, page, etc.) on a PHP 5.04 installation (Apache2, Debian Sarge). PHP warning: "Warning: strtotime() [function.strtotime]: Called with an empty time parameter. in /home/msb015/projects/drupal/modules/comment.module on line 448." Form error: "You have to specify a valid date." PHP5 backtrace: #0 comment_validate(Array ([subject] => test,[comment] => test,[format] => 1,[cid] => ,[pid] => 0,[nid] => 5,[uid] => )) called at [/home/msb015/projects/drupal/modules/comment.module:396] #1 comment_reply(5) called at [/home/msb015/projects/drupal/includes/menu.inc:354] #2 call_user_func_array(comment_reply, Array ([0] => 5)) called at [/home/msb015/projects/drupal/includes/menu.inc:354] #3 menu_execute_active_handler() called at [/home/msb015/projects/drupal/index.php:15] As you can tell, there isn't a 'date' key in $edit (what's passed to comment_validate()). After some debugging with the help of killes, we managed to fix the problem with the attached patch. The patch passes 'now' to strtotime() if edit['date'] didn't exist. michaelsb

1 0

[drupal-devel] [bug] use upload_tmp_dir as default for FILE_DIRECTORY_TEMP
by crunchywelch 03 Sep '05

03 Sep '05

Issue status update for http://drupal.org/node/26249 Post a follow up: http://drupal.org/project/comments/add/26249 Project: Drupal Version: 4.6.2 Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: danielc Updated by: crunchywelch -Status: active +Status: patch (code needs review) change status crunchywelch Previous comments: ------------------------------------------------------------------------ Sat, 02 Jul 2005 20:03:13 +0000 : danielc In includes/file.inc, the FILE_DIRECTORY_TEMP constant is set as follows: define('FILE_DIRECTORY_TEMP', IS_WINDOWS ? 'c:\\windows\\temp' : '/tmp'); It's wiser to set it to php.ini's upload_tmp_dir value: define('FILE_DIRECTORY_TEMP', ini_get('upload_tmp_dir')); I noticed this issue because I'm running Windows 2000, which defaults to an install directory of c:\winnt, not c:\windows. When I go to the "Settings" administration page, (while running PHP 5.0.5-dev) I got the following error at the top of the page: warning: mkdir() [function.mkdir]: No such file or directory in ...\includes\file.inc on line 86. ------------------------------------------------------------------------ Thu, 07 Jul 2005 13:05:36 +0000 : AlberT75 I had the same problem when installed on a host with open_base_dir enabled (it should be on a decent hoster machine)... ------------------------------------------------------------------------ Sat, 03 Sep 2005 21:42:49 +0000 : crunchywelch Attachment: http://drupal.org/files/issues/file.inc.patch (635 bytes) Here is a patch for this, seems like a good idea to me, works on a new HEAD install on SUSe Linux.

1 0

[drupal-devel] [bug] Users with 'maintain books' or 'edit own book pages' permission cannot delete book pages
by clydefrog 03 Sep '05

03 Sep '05

Issue status update for http://drupal.org/node/21559 Post a follow up: http://drupal.org/project/comments/add/21559 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: clydefrog Updated by: clydefrog Status: patch (code needs review) Your site behaved in that way because the users with "maintain books" permission did not have permission to use the input format defined for those nodes. This is a general feature of Drupal, not specific to the book module. clydefrog Previous comments: ------------------------------------------------------------------------ Fri, 29 Apr 2005 04:32:19 +0000 : clydefrog Attachment: http://drupal.org/files/issues/delete_own_book_pages.patch (626 bytes) AFAICT, only 'administer nodes' permission allows deletion of book pages. This patch allows users with 'maintain books' or 'edit own book pages' permission to delete book pages. The logic doesn't check if the node has updates pending. Should it? ------------------------------------------------------------------------ Fri, 29 Apr 2005 14:10:22 +0000 : clydefrog It's a patch, duh. ------------------------------------------------------------------------ Fri, 29 Apr 2005 14:21:27 +0000 : rivena If maintain books is a permission that overlaps other permissions, it should say so. For example, /maintain books (create, edit, and delete all book pages)/. While I agree that someone who has been given maintainer status should be able to delete pages, I wonder if 'delete own pages' should be made into a seperate permission. I could see a situation where I would not want someone to be able to delete their own pages. Do these permissions affect things that are not book pages but have been put into books? Anisa. It's /Golden Week/! ------------------------------------------------------------------------ Sat, 30 Apr 2005 03:43:17 +0000 : clydefrog I think it's clear that "maintain books" implies the ability to edit and delete book pages. No other node module provides a "delete own " permission, so it would be inconsistent for book.module to provide it. Can you provide some examples to justify the inconsistency? These permissions do not affect nodes which aren't book pages but are in a book. Those nodes are controlled by their respective type-specific permissions, but only users with "maintain books" permission can add or remove those nodes from books. I believe this is the correct behavior. ------------------------------------------------------------------------ Sat, 30 Apr 2005 11:03:47 +0000 : rivena Hmm... But, you just said that until this patch, it *didn't* include the delete pages permission. Right? So, now you are changing it's behavior, but leaving the wording the same. How will people know? Or does it not matter, because you presume they didn't really know it didn't include delete in the first place? I don't know that I can defend my idea of having a seperate delete own pages permission against a standard of consistency. If all the other edit own permissions include the delete pages permission, then I have no quibbles. :) Except it would be more userfriendly if I knew what the permissions meant before I granted them to someone, without having to look at the code. But I do realize that is completely out of the scope of the patch. :) Where do all these little changes *go*, anyway? The changelog just says things like... refractored the search module. Anisa. ------------------------------------------------------------------------ Sat, 30 Apr 2005 16:04:14 +0000 : clydefrog I believe that "maintain books" permission implies the ability to delete book pages, so this patch fixes that bug. Other node modules include deletion in the "edit own" permission. For example, page.module: <?php if ($op == 'update' || $op == 'delete') { if (user_access('edit own pages') && ($user->uid == $node->uid)) { return TRUE; } } ?> I agree that it would be better if permissions were clearer about what they implied. There was a discussion started by killes [1] a while ago: "One problem with Drupal is the way it handles user permissions. The permissions are attached to the user object but nobody really knows what they do. To find out what a particular permission allows you to do, you often need to have a look at the code. " I don't know if it ever lead to any code. I think the changelog is meant to list the changes since the previous version without too much technical detail. If you want to see every last change, take a look at the cvs messages [2]. [1] http://lists.drupal.org/archives/drupal-devel/2005-04/msg00704.html [2] http://drupal.org/project/cvs/3060 ------------------------------------------------------------------------ Mon, 23 May 2005 17:33:18 +0000 : rivena I've been looking at the book module permissions recently, and did a bit of testing. I wanted to know what was the minimum permissions needed to create a new book. I assumed based on this discussion, and a similar discussion on the drupal support list that this was 'maintain books' and 'administer nodes'. I ran into a problem, then added 'access nodes' to this. So now my user has no other permissions other than 'maintain books', 'administer nodes' and 'access nodes'. You'd think this is more than sufficient to do something simple like create a new book, but in fact, with just these permissions, you do not have access to create a book page. You can edit other pages, and move them into a new book. Once you have create pages permission, you appear to finally have all the permissions needed, edit own pages is not needed. So, since, the point of this patch was that not having delete permission was odd, might I suggest adding create permission to maintain books? ;p Anisa. ------------------------------------------------------------------------ Mon, 08 Aug 2005 10:37:49 +0000 : Bèr Kessels I would say this is a "by design". Maybe we need to rename the two book permissions into: "create books" and "edit own book pages". None of the other nodes can be deleted by the roles with "edit own Foo" permissions, nor should the books. ------------------------------------------------------------------------ Mon, 08 Aug 2005 16:59:30 +0000 : clydefrog Thanks for your review, Ber. story.module [3] allows users with "edit own stories" permission to delete stories. <?php if ($op == 'update' || $op == 'delete') { if (user_access('edit own stories') && ($user->uid == $node->uid)) { return TRUE; } } ?> Therefore it is not inconsistent for the same behavior to apply to book nodes. If "maintain books" really means "create books", then the name should be changed and existing code in book.module needs to be updated. However, I think "maintain books" should allow more than just that. In my situation, I want to be able to give someone the permissions to create books and to create, edit, and delete all book pages. With my patch, "maintain books" and "create book pages" does that. [3] http://cvs.drupal.org/viewcvs/drupal/drupal/modules/story.module?rev=1.167&… ------------------------------------------------------------------------ Mon, 08 Aug 2005 19:16:35 +0000 : Bèr Kessels What i see from story, that is specific to story.module too. We should really settle for a consistent behaviour for *all* nodes, one that is "enforced" from node.module. These things should really not be decided per node-type and per-module. Thats a recipe for a mess. ------------------------------------------------------------------------ Mon, 08 Aug 2005 19:25:27 +0000 : Eric Scouten I agree that the current system is a mess. I disagree that there should be one consistent policy enforced by node.module. Sites may have quite legitimate reasons to have different policies for different node types. ------------------------------------------------------------------------ Mon, 08 Aug 2005 20:35:59 +0000 : Bèr Kessels What i was aiming at is to let node module take care of the following: * edit $node_type * administer $node_type * delete $node_type (but would that not better be in 'administer';: users who can administer can delete) * create $node_type That way the modules need not cre about this. ut they /can/ take care of it, if they wish, and add more rules and permissions. ------------------------------------------------------------------------ Mon, 08 Aug 2005 20:36:32 +0000 : Bèr Kessels oh, and -forgot- : * view $node_type ------------------------------------------------------------------------ Mon, 08 Aug 2005 20:49:31 +0000 : Eric Scouten Thanks for the clarification, Bèr. I was afraid that you meant that there would be a single policy applied to *all* node types, not a policy *per* node type. Now I think we're in complete agreement on this subject. ------------------------------------------------------------------------ Mon, 08 Aug 2005 20:51:13 +0000 : puregin I think it's important to keep a clean separation between content and structure (e.g., what's inside of the node, versus how the node is associated with other nodes) I think that there will likely be other explicit structures in Drupal over time, so these concerns affect more than just book module. Deleting a node from a book is potentially a problem, since this operation affects the structure of a book. We also need to think about other interactions with structure - for example, what happens if someone unpublished a node in a book? Should all children also be unpublished? Should the node contents be hidden, while children remain available in navigation? ------------------------------------------------------------------------ Mon, 08 Aug 2005 21:08:01 +0000 : Bèr Kessels puregrin. I think you are gettnig OT here, Thought it is a very valid (and problematic) issue, It really belongs in a new thread. ------------------------------------------------------------------------ Mon, 08 Aug 2005 22:57:34 +0000 : puregin What I was saying is that whether a user should be able to delete a node from a structure should really be enforced by the module which is responsible for the structure. For example, imagining a simple linear list structure - let's say for a "wish list" - composed of nodes owned by a bunch of different users. In this example, a user could delete his own node with no problem. For the book module, a users node may have children authored by other users. Letting an arbitrary user delete his own node would be, I think, a mistake, since the children would then be orphaned. I suppose one could imagine other modules which rely on a hierarchy, which might have a different policy (e.g., automatically attach children to the parent of the deleted node, if such a node exists). Perhaps eventually two 'tree-based' structure modules might inherit from a tree structure module, each enforcing separate policies regarding node operations. The point is, that one should not have to modify node module when a new structure is defined. Node module should not have to know about how composites of nodes work. ------------------------------------------------------------------------ Tue, 09 Aug 2005 00:45:07 +0000 : Boris Mann puregin: I was talking about this today, so I created a task [4] to remind us to build a generalized node relationship module/schema. [4] http://drupal.org/node/28480 ------------------------------------------------------------------------ Fri, 12 Aug 2005 00:42:58 +0000 : Crell /I think it's clear that "maintain books" implies the ability to edit and delete book pages./ I'm afraid I have to disagree with clydefrog on this one. The words "administer" and "maintain" and "manage" don't give any firm indication of what they mean, in and of themselves. They could vary depending on the context. Some nodes are deleteable in the fist place, some aren't. In that case, "maintain" means two different things, as would anything else you put in there unqualified. This isn't just a problem with the books module, but in general. It is not intuitively obvious what "administer nodes" or "administer X" means. That's a problem, especially when, as I said, it can vary from one node type to another. I see, generally, the following types of operations on nodes: - Create - Change Ownership - View Anyone's - View Own - Edit Anyone's - Edit Own - Delete Anyone's - Delete Own Which of those is covered by "administer" or "maintain"? And what if I want to allow someone to, say, edit their own nodes, but not delete them? Or allow a given class of administrator to edit anyone's nodes but not delete any but their own? I'd actually be much in favor of more fine-grained control over nodes access rights, both for the greater power it offers and for the clearer UI, system-wide. Whether that's best done via a central node API system or via a "recommended permission breakdown" I don't know, and will leave that to those who have spent more time with core than I have. :-) I do believe it's a good idea, however, both for greater flexibility and greater learnability. ------------------------------------------------------------------------ Fri, 26 Aug 2005 21:23:27 +0000 : noid Just to clarify things -- based on tests I did with the book module -- (the following hold true for regular users with no "administer nodes" permission) *1) the "edit own book pages" does not give the user the option to delete his own pages.* and *2) "maintain books" doesn't do anything. * This is the state of things right now, right? If this is so, may I suggest that the initial fix be simple in the meantime which should include: *1) "edit own book pages" means the user /can also delete his own pages./* *2) "maintain books" means the user /can edit (but not delete) pages created by other users./* ******************** I've also noticed that "create book pages" (or "edit own book pages" and "maintain books" for that matter) doesn't allow the user to create a top-level page -- there's no option for it in the pulldown. Can this be fixed so that * "create book pages" allow the user to create a top-level page (that is start his own book)?* ------------------------------------------------------------------------ Tue, 30 Aug 2005 14:14:42 +0000 : noid My bad. *"Maintain books" works after all.* Tested the permission again and found out that a user with the aforementioned access can edit some of the nodes after all, and these nodes were created after a certain date. So I looked into the modules I installed after that date, and, to cut to the chase, found out that the culprit was TinyMCE. Well, indirectly, that is. :) Turned out I was using a new customized input format -- per advice of TinyMCE install instructions -- and the older nodes that were created with the default filtered HTML format couldn't be edited. So all I have to do now is change the input format of these older nodes to the new input format I set for TinyMCE. :) At any rate, perhaps someone can figure out why the new format made the book module act that way. :)

1 0

[drupal-devel] [bug] After creating a book, empty book divs shouldn't be created
by crunchywelch 03 Sep '05

03 Sep '05

Issue status update for http://drupal.org/node/13099 Post a follow up: http://drupal.org/project/comments/add/13099 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: FactoryJoe(a)civicspacelabs.org Updated by: crunchywelch Status: patch (code needs review) Attachment: http://drupal.org/files/issues/book.module_8.patch (3.06 KB) Seems I tried to sneak in my timezone system.module patch as well ;). Here is a patch without the system.module diff. crunchywelch Previous comments: ------------------------------------------------------------------------ Thu, 18 Nov 2004 02:09:07 +0000 : FactoryJoe(a)civicspacelabs.org Attachment: http://drupal.org/files/issues/book_divs.png (9.83 KB) This code creates a styled section beneath a new book: <div class="book"><div class="nav"> <div class="links"><div class="prev"> </div><div class="next"> </div></div> <div class="titles"></div></div></div> </div> If there is no data to be displayed, empty divs should not be output. ------------------------------------------------------------------------ Thu, 16 Jun 2005 18:26:57 +0000 : Robin Monks The <div class="book"><div class="nav"> <div class="links"><div class="prev"> </div><div class="next"> </div></div> <div class="titles"></div></div></div></div> still exists. Bumping up to HEAD. Robin ------------------------------------------------------------------------ Sat, 03 Sep 2005 21:28:48 +0000 : crunchywelch Attachment: http://drupal.org/files/issues/book.module_7.patch (7.89 KB) Here is a patch that fixes this, it rearranges the theme_book_navigation function logic to only output the navigation book div if there is content to display.

1 0

[drupal-devel] [bug] After creating a book, empty book divs shouldn't be created
by crunchywelch 03 Sep '05

03 Sep '05

Issue status update for http://drupal.org/node/13099 Post a follow up: http://drupal.org/project/comments/add/13099 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: FactoryJoe(a)civicspacelabs.org Updated by: crunchywelch -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/book.module_7.patch (7.89 KB) Here is a patch that fixes this, it rearranges the theme_book_navigation function logic to only output the navigation book div if there is content to display. crunchywelch Previous comments: ------------------------------------------------------------------------ Thu, 18 Nov 2004 02:09:07 +0000 : FactoryJoe(a)civicspacelabs.org Attachment: http://drupal.org/files/issues/book_divs.png (9.83 KB) This code creates a styled section beneath a new book: <div class="book"><div class="nav"> <div class="links"><div class="prev"> </div><div class="next"> </div></div> <div class="titles"></div></div></div> </div> If there is no data to be displayed, empty divs should not be output. ------------------------------------------------------------------------ Thu, 16 Jun 2005 18:26:57 +0000 : Robin Monks The <div class="book"><div class="nav"> <div class="links"><div class="prev"> </div><div class="next"> </div></div> <div class="titles"></div></div></div></div> still exists. Bumping up to HEAD. Robin

1 0

[drupal-devel] [bug] Can't delete subjects with '&' in title
by Cvbge 03 Sep '05

03 Sep '05

Issue status update for http://drupal.org/node/27140 Post a follow up: http://drupal.org/project/comments/add/27140 Project: Drupal Version: cvs Component: contact.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: Cvbge -Status: active +Status: patch (code needs work) Hi, 0. You should keep all changes in one file, i.e. pake one patch, not patch for every file 1. You should include changes for database/database.{mysql,pgsql} 2. IIRC auto_increment was depreciated, you should use db_next_id() (but I see auto_increment in cvs...) 3. You use "WHERE cid = '%s'", but cid is integer so this should probably be %d (although this probably would not break anything..) Cvbge Previous comments: ------------------------------------------------------------------------ Wed, 20 Jul 2005 14:57:03 +0000 : m3avrck Using the site-wide contact forms, any subjects with an '&' cannot be deleted. Clicking delete for these subjects brings up the expected action flow, however, confirming the delete does nothing. Subject still exists. ------------------------------------------------------------------------ Mon, 25 Jul 2005 13:45:38 +0000 : m3avrck It appears this issue might be linked with this one: http://drupal.org/node/23685 A problem with mod_rewrite and not the actual contact module. ------------------------------------------------------------------------ Wed, 31 Aug 2005 16:51:56 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/contact.module_6.patch (4.7 KB) Redid how contacts work. It now references contacts by ID instead of their category as the unique identifier. It also allows for contacts to have weights, so that one may control where the contact will appear in the listing. ------------------------------------------------------------------------ Wed, 31 Aug 2005 16:53:01 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/updates.inc (27.23 KB) This is the update.inc for the database cahnges that goes along with this patch. ------------------------------------------------------------------------ Wed, 31 Aug 2005 18:31:37 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/contact.module_7.patch (4.5 KB) Updated patch. ------------------------------------------------------------------------ Wed, 31 Aug 2005 18:31:55 +0000 : Souvent22 Attachment: http://drupal.org/files/issues/updates.inc_4.patch (1.29 KB) Updated database patch.

1 0