- Development - lists.drupal.org

[drupal-devel] [bug] User info should not be visible without permission
by killes 12 Apr '05

12 Apr '05

Issue status update for http://drupal.org/node/4166 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: normal Assigned to: killes(a)www.drop.org Reported by: mic Updated by: killes(a)www.drop.org Status: patch Attachment: http://drupal.org/files/issues/user-db_0.patch (2.45 KB) killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ November 17, 2003 - 06:23 : mic When anonymous visitors do not have "Access userlist" permission, they can still view all the public info in user profiles. Drupal sites that are created for a group of friends or for an organization want to protect their e-mail addresses, telephone numbers and so on, while making these accessible to fellow members. This could be a critical feature request, but since I think it's an error, I'm sending you this as bug. (I don't have CVS, so I'm hoping someone else will make the simple correction needed to the user module) ------------------------------------------------------------------------ February 3, 2004 - 05:41 : daBrado Attachment: http://drupal.org/files/issues/user-module-add-view-permission.patch (1.54 KB) I made a patch that fixed this by adding a new permission, "access users". This is everything this patch does: Add new permission, "access users" If a user does not have the "access users" permission, s/he cannot read another user's profile at all, and instead gets an "access denied" page. I hope I did this in the proper way. ------------------------------------------------------------------------ April 21, 2004 - 20:25 : Dries I think we should not introduce a new permission but merge with the existing 'access user list' permission (or rename it to 'access users'). Marking this "won't fix" until the patch has been udpated. ------------------------------------------------------------------------ May 28, 2004 - 02:26 : daBrado Attachment: http://drupal.org/files/issues/user-module-add-view-permission_0.patch (1.88 KB) Another patch, this time renaming the permission "access user list" to "access users", and adding a check in the user viewing function to only allow users with this permission to view the user information. ------------------------------------------------------------------------ July 5, 2004 - 15:31 : Anonymous Attachment: http://drupal.org/files/issues/user-module-add-view-permission_1.patch (1.86 KB) Here is a patch again, now for CVS. Does the same thing as above. It is a very simple patch. If it seems proper, I hope that can be included before it goes stale. ------------------------------------------------------------------------ July 9, 2004 - 02:08 : daBrado Attachment: http://drupal.org/files/issues/user-module-add-view-permission_2.patch (1.33 KB) The previous patch was accepted, but then for some reason reversed as part of another CVS commit. So, here is a new patch that brings back the "access users" permission. It controls whether or not a user may view other users info. ------------------------------------------------------------------------ September 22, 2004 - 16:53 : Bèr Kessels Attachment: http://drupal.org/files/issues/access_users_perm.patch (6.46 KB) A new and revised patch. It adds an "access users" permission ------------------------------------------------------------------------ September 22, 2004 - 18:02 : killes(a)www.drop.org I'd like to see this patch applied to cvs before the 4.5 release. Now that we can protect our nodes from unauthorized access it just makes sense to protect our user data as well. In the future I'd like to see scheme where the user (as in end-user) is able to selet which of his data gets published. ------------------------------------------------------------------------ September 23, 2004 - 01:52 : rkendall I would like this too ------------------------------------------------------------------------ October 14, 2004 - 23:46 : drumm Can the name be changed to 'view user profiles'? ------------------------------------------------------------------------ October 18, 2004 - 09:19 : Bèr Kessels It can, but I used "access" for consistancy. we have "access newsfeeds", "access comments", "access etc". This patch is critical for corporate sites btw. A corporate site that has its customers information lying on the streets (so to say) is not-done. Ber ------------------------------------------------------------------------ November 27, 2004 - 13:49 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user-access.patch (5.96 KB) Updated for CVS. I assumed that "admin users" implies "access users" in user_admin. ------------------------------------------------------------------------ March 1, 2005 - 17:30 : killes(a)www.drop.org Does not apply anymore, Ber can you have a look at it? ------------------------------------------------------------------------ March 7, 2005 - 09:19 : Bèr Kessels Attachment: http://drupal.org/files/issues/user_access_0.patch (9.74 KB) New patch. Should apply to HEAD. ------------------------------------------------------------------------ April 7, 2005 - 21:29 : killes(a)www.drop.org It's a patch (which still applies and wants into core). ------------------------------------------------------------------------ April 8, 2005 - 18:10 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user_access_bug_1.patch (11.45 KB) Ok, updated patch. Includes changes to format_name to only display unlinked username for non-privileddged users. 'acccess users' is now 'access user profiles'. The search users tab won't get displayed either if you are not allowed to seee user profiles. The patch got even tested. ------------------------------------------------------------------------ April 8, 2005 - 18:19 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user_access_bug_2.patch (11.26 KB) Further testing revealed a bug in the older parts of the patch... ------------------------------------------------------------------------ April 8, 2005 - 20:02 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user_access_bug_3.patch (11.35 KB) Another iteration: Users should alwys be allowed to see their own user page. ------------------------------------------------------------------------ April 11, 2005 - 23:49 : Steven Committed to 4.6/HEAD. ------------------------------------------------------------------------ April 12, 2005 - 00:04 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user-db.patch (2.56 KB) We found that users should not wonder why they cannot see other users' pages anymore. DB update required. Patch for HEAD attached, 4.6 to follow.

1 0

[drupal-devel] [bug] User info should not be visible without permission
by killes 12 Apr '05

12 Apr '05

Issue status update for http://drupal.org/node/4166 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: normal -Assigned to: Anonymous +Assigned to: killes(a)www.drop.org Reported by: mic Updated by: killes(a)www.drop.org -Status: fixed +Status: patch Attachment: http://drupal.org/files/issues/user-db.patch (2.56 KB) We found that users should not wonder why they cannot see other users' pages anymore. DB update required. Patch for HEAD attached, 4.6 to follow. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ November 17, 2003 - 06:23 : mic When anonymous visitors do not have "Access userlist" permission, they can still view all the public info in user profiles. Drupal sites that are created for a group of friends or for an organization want to protect their e-mail addresses, telephone numbers and so on, while making these accessible to fellow members. This could be a critical feature request, but since I think it's an error, I'm sending you this as bug. (I don't have CVS, so I'm hoping someone else will make the simple correction needed to the user module) ------------------------------------------------------------------------ February 3, 2004 - 05:41 : daBrado Attachment: http://drupal.org/files/issues/user-module-add-view-permission.patch (1.54 KB) I made a patch that fixed this by adding a new permission, "access users". This is everything this patch does: Add new permission, "access users" If a user does not have the "access users" permission, s/he cannot read another user's profile at all, and instead gets an "access denied" page. I hope I did this in the proper way. ------------------------------------------------------------------------ April 21, 2004 - 20:25 : Dries I think we should not introduce a new permission but merge with the existing 'access user list' permission (or rename it to 'access users'). Marking this "won't fix" until the patch has been udpated. ------------------------------------------------------------------------ May 28, 2004 - 02:26 : daBrado Attachment: http://drupal.org/files/issues/user-module-add-view-permission_0.patch (1.88 KB) Another patch, this time renaming the permission "access user list" to "access users", and adding a check in the user viewing function to only allow users with this permission to view the user information. ------------------------------------------------------------------------ July 5, 2004 - 15:31 : Anonymous Attachment: http://drupal.org/files/issues/user-module-add-view-permission_1.patch (1.86 KB) Here is a patch again, now for CVS. Does the same thing as above. It is a very simple patch. If it seems proper, I hope that can be included before it goes stale. ------------------------------------------------------------------------ July 9, 2004 - 02:08 : daBrado Attachment: http://drupal.org/files/issues/user-module-add-view-permission_2.patch (1.33 KB) The previous patch was accepted, but then for some reason reversed as part of another CVS commit. So, here is a new patch that brings back the "access users" permission. It controls whether or not a user may view other users info. ------------------------------------------------------------------------ September 22, 2004 - 16:53 : Bèr Kessels Attachment: http://drupal.org/files/issues/access_users_perm.patch (6.46 KB) A new and revised patch. It adds an "access users" permission ------------------------------------------------------------------------ September 22, 2004 - 18:02 : killes(a)www.drop.org I'd like to see this patch applied to cvs before the 4.5 release. Now that we can protect our nodes from unauthorized access it just makes sense to protect our user data as well. In the future I'd like to see scheme where the user (as in end-user) is able to selet which of his data gets published. ------------------------------------------------------------------------ September 23, 2004 - 01:52 : rkendall I would like this too ------------------------------------------------------------------------ October 14, 2004 - 23:46 : drumm Can the name be changed to 'view user profiles'? ------------------------------------------------------------------------ October 18, 2004 - 09:19 : Bèr Kessels It can, but I used "access" for consistancy. we have "access newsfeeds", "access comments", "access etc". This patch is critical for corporate sites btw. A corporate site that has its customers information lying on the streets (so to say) is not-done. Ber ------------------------------------------------------------------------ November 27, 2004 - 13:49 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user-access.patch (5.96 KB) Updated for CVS. I assumed that "admin users" implies "access users" in user_admin. ------------------------------------------------------------------------ March 1, 2005 - 17:30 : killes(a)www.drop.org Does not apply anymore, Ber can you have a look at it? ------------------------------------------------------------------------ March 7, 2005 - 09:19 : Bèr Kessels Attachment: http://drupal.org/files/issues/user_access_0.patch (9.74 KB) New patch. Should apply to HEAD. ------------------------------------------------------------------------ April 7, 2005 - 21:29 : killes(a)www.drop.org It's a patch (which still applies and wants into core). ------------------------------------------------------------------------ April 8, 2005 - 18:10 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user_access_bug_1.patch (11.45 KB) Ok, updated patch. Includes changes to format_name to only display unlinked username for non-privileddged users. 'acccess users' is now 'access user profiles'. The search users tab won't get displayed either if you are not allowed to seee user profiles. The patch got even tested. ------------------------------------------------------------------------ April 8, 2005 - 18:19 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user_access_bug_2.patch (11.26 KB) Further testing revealed a bug in the older parts of the patch... ------------------------------------------------------------------------ April 8, 2005 - 20:02 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user_access_bug_3.patch (11.35 KB) Another iteration: Users should alwys be allowed to see their own user page. ------------------------------------------------------------------------ April 11, 2005 - 23:49 : Steven Committed to 4.6/HEAD.

1 0

[drupal-devel] [bug] user_save field deletion comment move to phpdoc
by chx 11 Apr '05

11 Apr '05

Issue status update for http://drupal.org/node/20338 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/user_module_doc.patch (953 bytes) I asked about five times in #drupal how the heck could I delete a user field's value, before moshe said something which led me to find this obscure placed comment. Move it to phpdoc, it's important. Applies to 4.6 and HEAD. chx

1 0

[drupal-devel] [feature] Add Folksonomy, or "Free Tagging", to Taxonomy
by Morbus Iff 11 Apr '05

11 Apr '05

Issue status update for http://drupal.org/node/19697 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff Status: patch Attachment: http://drupal.org/files/issues/taxonomy_all.patch (19.53 KB) This patch adds folksonomy support to Drupal (named internally as "Free tagging"). In a nutshell, the core difference is the input method: unlike normal taxonomies which are administratively controlled, a "free tagging" vocabulary allows tag creation when the node is submitted. It does this through an text input box, as opposed to a dropdown or selectbox. This patch: Removes the useless "Preview form" of a vocabulary. Alters the vocabulary table to include a new "tags" column. Adds a new "Free tagging" preference on vocabulary creation/editing. Modifies the vocabulary overview to support pagers for free tagging vocabs. The new code integrates tightly with the existing taxonomy code. The only additional processing occurs on node save and edit, where we parse through the tags associated with a node. All other display (and thus, code) remains the same. The following screenshots illustrate the changes, integration, and workflow: Create/edit vocabulary screen. [1] Create/edit a node. [2] Result of previous screen. [3] The new admin/taxonomy. [4] Clicking on \"view terms\". [5] These patches were made during the exploration and customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus(a)disobey.com. [1] http://disobey.com/detergent/2005/drupal_folkdef.jpg [2] http://disobey.com/detergent/2005/drupal_folknodeedit.jpg [3] http://disobey.com/detergent/2005/drupal_folknodesubmit.jpg [4] http://disobey.com/detergent/2005/drupal_folkpager1.jpg [5] http://disobey.com/detergent/2005/drupal_folkpager2.jpg Morbus Iff

17 49

[drupal-devel] [feature] Always show node->type on node edit page
by Dries 11 Apr '05

11 Apr '05

Issue status update for http://drupal.org/node/20228 Project: Drupal Version: cvs Component: node system Category: feature requests Priority: normal Assigned to: Robin Monks Reported by: robertDouglass Updated by: Dries Status: patch It is better if the page title remains constant when clicking tabs (that is also consistent with the rest of Drupal). Dries Previous comments: ------------------------------------------------------------------------ April 9, 2005 - 20:27 : robertDouglass Wen creating a node there is a nice h1 title saying "Submit {node type}". When returning to the node edit form later this information is gone. Many node types are indistinguishable from another based on the form alone (page, story, blog...), so I think it would be a rather nice feature to always state which node type is being edited. ------------------------------------------------------------------------ April 10, 2005 - 00:01 : Robin Monks Taking request... ------------------------------------------------------------------------ April 10, 2005 - 00:57 : Robin Monks Attachment: http://drupal.org/files/issues/Edit Title.patch (601 bytes) This patch shows "Editing /contenttype/ /contenttitle/". Example: "Editing blog As the World Turns". Robin Monks moznetwork.org ------------------------------------------------------------------------ April 10, 2005 - 01:17 : Robin Monks Attachment: http://drupal.org/files/issues/Edit Title_0.patch (701 bytes) Actualy, I made an error in that patch. This should be correct. Robin

1 0

[drupal-devel] [bug] Blocks with no title kill Drupal
by Dries 11 Apr '05

11 Apr '05

Issue status update for http://drupal.org/node/19965 Project: Drupal Version: cvs Component: block.module Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: budda Updated by: Dries Status: patch I'm OK with this patch but suggest that we look into improving the error message. Small nit: fix the spacing around '=' in the SQL query that checks for duplicates. Dries Previous comments: ------------------------------------------------------------------------ April 4, 2005 - 19:03 : budda When setting more than one block's title to '' (blank) Drupal dies, and doesn't catch the SQL query error nicely. The error is as follows: user error: Duplicate entry '' for key 2 query: UPDATE boxes SET title = '', body = ' ...<cut>... in /var/www/html/drupal-cvs/includes/database.mysql.inc on line 66. Using 4.6 build from 4/4/2005 The page ends with: warning: Cannot modify header information - headers already sent by (output started at /var/www/html/drupal-cvs/includes/common.inc:384) in /var/www/html/drupal-cvs/includes/common.inc on line 192. ------------------------------------------------------------------------ April 8, 2005 - 10:08 : robertDouglass There should be a check before the insert is attempted and if the block title already exists the user should be notified with form_error(). ------------------------------------------------------------------------ April 8, 2005 - 11:46 : Poolio this certainly doesn't solve the problem, but I've worked around this issue by using html tags in the title field for blocks that I don't want to show a title. ------------------------------------------------------------------------ April 9, 2005 - 02:31 : Robin Monks Attachment: http://drupal.org/files/issues/block.module.blank.title.patch (955 bytes) A small patch that checks to ensure the title does not already exit in the Blocks list. Also, if the field was left blank, in adds an HTML comment with the current date to the second to ensure that a duplicate title isn't created. This is my first patch, so I probably did something wrong, but I'm willing to fix it too. Robin Monks MozNetwork.org ------------------------------------------------------------------------ April 9, 2005 - 03:22 : Morbus Iff I'm, personally, fine with how you've fixed the blank block title. You've really solved two problems in one: duplicate titles (which is the cause of this Issue), and the desire to have blank (or no) titles (which is the reason for this Issue) for the end user. With that said, I'm not a fan of your error message (but, then again, anal wording is my specialty, so don't think I'm picking on you): I'd rename it to "That block title is already in use; please choose another." The goals here: The user may not remember all the previous titles he's used. Using "unique" starts forcing him to remember. We shouldn't do that. The user already knows he entered it - we don't have to repeat that to him. It's active, not passive (no use of "have"). Use a semi-colon, not a comma. It's much shorter and concise. ------------------------------------------------------------------------ April 9, 2005 - 08:27 : chx Attachment: http://drupal.org/files/issues/box_title.patch (1.49 KB) Why display any message at all? ------------------------------------------------------------------------ April 9, 2005 - 16:11 : Morbus Iff Displaying no message at all would only work if the user wasn't typing in ANY title whatsoever (since then we'd make one for them based on the date). But, if a user names a block "Users" one week, and then creates another block called "Users" three weeks later, than an whoopsidaisy error needs to be shown - we shouldn't modify the text randomly. ------------------------------------------------------------------------ April 9, 2005 - 17:10 : chx Well, let's discuss the main point: why shoiuld be the title unique? ------------------------------------------------------------------------ April 9, 2005 - 17:38 : Morbus Iff Are you asking why Drupal enforces them being unique, or why, visually and to the end-user, they should be unique? ------------------------------------------------------------------------ April 9, 2005 - 17:43 : chx I guess Drupal forces them 'cos for some reasons it is thought that for the users they should be unique. This is not the case, however. Yes, it's confusing if they are on the same page. But I can think on circumstances where they would not be on the same page, so the force from Drupal seems unnecessary. ------------------------------------------------------------------------ April 9, 2005 - 21:00 : robertDouglass agree with chx on the unique point. Like the functionality of adding html comments and timestamp (why timestamp? why not a block id?) if left blank if they must be uniqe. Would be in favor of making the visible title completely optional. Administrators have description to keep them separate on the admin screen. ------------------------------------------------------------------------ April 9, 2005 - 21:48 : Robin Monks Attachment: http://drupal.org/files/issues/drupal_0.patch (3.67 KB) This new patch no longer requires a unique value for title, and also checks to ensure the Block Description is not a duplicate or empty value. Big thanks go out to chx for assistance. Robin ------------------------------------------------------------------------ April 11, 2005 - 16:20 : Anonymous Shouldn't we add a test too to check info unicity ? ------------------------------------------------------------------------ April 11, 2005 - 16:38 : chx <?php if (empty($edit['info']) || db_num_rows(db_query("SELECT info FROM {boxes} WHERE info='%s'", $edit['info']))) { ?> To me, this seems like a check for info unicity... not to mention that the UNIQUE(info) DB constraint is not touched. ------------------------------------------------------------------------ April 11, 2005 - 16:46 : tostinni Ups, sorry for the anonymous and the message, I didn't saw this verification, I was only remembering block.module code. That's all fine for me. ------------------------------------------------------------------------ April 11, 2005 - 18:27 : njivy +1 to Robin Monks' patch. When I install Drupal, the first thing I always do is remove the /unique key/ constraint on block titles. I have not tested the other parts of Monks' patch, though, including the uniqueness constraint on block descriptions. ------------------------------------------------------------------------ April 11, 2005 - 21:04 : drumm Code looks okay. +1 "You must enter unique data into the block description field." doesn't sound like the friendliest of error messages.

1 0

[drupal-devel] [bug] Blocks with no title kill Drupal
by drumm 11 Apr '05

11 Apr '05

Issue status update for http://drupal.org/node/19965 Project: Drupal Version: cvs Component: block.module Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: budda Updated by: drumm Status: patch Code looks okay. +1 "You must enter unique data into the block description field." doesn't sound like the friendliest of error messages. drumm Previous comments: ------------------------------------------------------------------------ April 4, 2005 - 11:03 : budda When setting more than one block's title to '' (blank) Drupal dies, and doesn't catch the SQL query error nicely. The error is as follows: user error: Duplicate entry '' for key 2 query: UPDATE boxes SET title = '', body = ' ...<cut>... in /var/www/html/drupal-cvs/includes/database.mysql.inc on line 66. Using 4.6 build from 4/4/2005 The page ends with: warning: Cannot modify header information - headers already sent by (output started at /var/www/html/drupal-cvs/includes/common.inc:384) in /var/www/html/drupal-cvs/includes/common.inc on line 192. ------------------------------------------------------------------------ April 8, 2005 - 02:08 : robertDouglass There should be a check before the insert is attempted and if the block title already exists the user should be notified with form_error(). ------------------------------------------------------------------------ April 8, 2005 - 03:46 : Poolio this certainly doesn't solve the problem, but I've worked around this issue by using html tags in the title field for blocks that I don't want to show a title. ------------------------------------------------------------------------ April 8, 2005 - 18:31 : Robin Monks Attachment: http://drupal.org/files/issues/block.module.blank.title.patch (955 bytes) A small patch that checks to ensure the title does not already exit in the Blocks list. Also, if the field was left blank, in adds an HTML comment with the current date to the second to ensure that a duplicate title isn't created. This is my first patch, so I probably did something wrong, but I'm willing to fix it too. Robin Monks MozNetwork.org ------------------------------------------------------------------------ April 8, 2005 - 19:22 : Morbus Iff I'm, personally, fine with how you've fixed the blank block title. You've really solved two problems in one: duplicate titles (which is the cause of this Issue), and the desire to have blank (or no) titles (which is the reason for this Issue) for the end user. With that said, I'm not a fan of your error message (but, then again, anal wording is my specialty, so don't think I'm picking on you): I'd rename it to "That block title is already in use; please choose another." The goals here: The user may not remember all the previous titles he's used. Using "unique" starts forcing him to remember. We shouldn't do that. The user already knows he entered it - we don't have to repeat that to him. It's active, not passive (no use of "have"). Use a semi-colon, not a comma. It's much shorter and concise. ------------------------------------------------------------------------ April 9, 2005 - 00:27 : chx Attachment: http://drupal.org/files/issues/box_title.patch (1.49 KB) Why display any message at all? ------------------------------------------------------------------------ April 9, 2005 - 08:11 : Morbus Iff Displaying no message at all would only work if the user wasn't typing in ANY title whatsoever (since then we'd make one for them based on the date). But, if a user names a block "Users" one week, and then creates another block called "Users" three weeks later, than an whoopsidaisy error needs to be shown - we shouldn't modify the text randomly. ------------------------------------------------------------------------ April 9, 2005 - 09:10 : chx Well, let's discuss the main point: why shoiuld be the title unique? ------------------------------------------------------------------------ April 9, 2005 - 09:38 : Morbus Iff Are you asking why Drupal enforces them being unique, or why, visually and to the end-user, they should be unique? ------------------------------------------------------------------------ April 9, 2005 - 09:43 : chx I guess Drupal forces them 'cos for some reasons it is thought that for the users they should be unique. This is not the case, however. Yes, it's confusing if they are on the same page. But I can think on circumstances where they would not be on the same page, so the force from Drupal seems unnecessary. ------------------------------------------------------------------------ April 9, 2005 - 13:00 : robertDouglass agree with chx on the unique point. Like the functionality of adding html comments and timestamp (why timestamp? why not a block id?) if left blank if they must be uniqe. Would be in favor of making the visible title completely optional. Administrators have description to keep them separate on the admin screen. ------------------------------------------------------------------------ April 9, 2005 - 13:48 : Robin Monks Attachment: http://drupal.org/files/issues/drupal_0.patch (3.67 KB) This new patch no longer requires a unique value for title, and also checks to ensure the Block Description is not a duplicate or empty value. Big thanks go out to chx for assistance. Robin ------------------------------------------------------------------------ April 11, 2005 - 08:20 : Anonymous Shouldn't we add a test too to check info unicity ? ------------------------------------------------------------------------ April 11, 2005 - 08:38 : chx <?php if (empty($edit['info']) || db_num_rows(db_query("SELECT info FROM {boxes} WHERE info='%s'", $edit['info']))) { ?> To me, this seems like a check for info unicity... not to mention that the UNIQUE(info) DB constraint is not touched. ------------------------------------------------------------------------ April 11, 2005 - 08:46 : tostinni Ups, sorry for the anonymous and the message, I didn't saw this verification, I was only remembering block.module code. That's all fine for me. ------------------------------------------------------------------------ April 11, 2005 - 10:27 : njivy +1 to Robin Monks' patch. When I install Drupal, the first thing I always do is remove the /unique key/ constraint on block titles. I have not tested the other parts of Monks' patch, though, including the uniqueness constraint on block descriptions.

1 0

[drupal-devel] [bug] Blocks with no title kill Drupal
by njivy 11 Apr '05

11 Apr '05

Issue status update for http://drupal.org/node/19965 Project: Drupal Version: cvs Component: block.module Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: budda Updated by: njivy Status: patch +1 to Robin Monks' patch. When I install Drupal, the first thing I always do is remove the /unique key/ constraint on block titles. I have not tested the other parts of Monks' patch, though, including the uniqueness constraint on block descriptions. njivy Previous comments: ------------------------------------------------------------------------ April 4, 2005 - 11:03 : budda When setting more than one block's title to '' (blank) Drupal dies, and doesn't catch the SQL query error nicely. The error is as follows: user error: Duplicate entry '' for key 2 query: UPDATE boxes SET title = '', body = ' ...<cut>... in /var/www/html/drupal-cvs/includes/database.mysql.inc on line 66. Using 4.6 build from 4/4/2005 The page ends with: warning: Cannot modify header information - headers already sent by (output started at /var/www/html/drupal-cvs/includes/common.inc:384) in /var/www/html/drupal-cvs/includes/common.inc on line 192. ------------------------------------------------------------------------ April 8, 2005 - 02:08 : robertDouglass There should be a check before the insert is attempted and if the block title already exists the user should be notified with form_error(). ------------------------------------------------------------------------ April 8, 2005 - 03:46 : Poolio this certainly doesn't solve the problem, but I've worked around this issue by using html tags in the title field for blocks that I don't want to show a title. ------------------------------------------------------------------------ April 8, 2005 - 18:31 : Robin Monks Attachment: http://drupal.org/files/issues/block.module.blank.title.patch (955 bytes) A small patch that checks to ensure the title does not already exit in the Blocks list. Also, if the field was left blank, in adds an HTML comment with the current date to the second to ensure that a duplicate title isn't created. This is my first patch, so I probably did something wrong, but I'm willing to fix it too. Robin Monks MozNetwork.org ------------------------------------------------------------------------ April 8, 2005 - 19:22 : Morbus Iff I'm, personally, fine with how you've fixed the blank block title. You've really solved two problems in one: duplicate titles (which is the cause of this Issue), and the desire to have blank (or no) titles (which is the reason for this Issue) for the end user. With that said, I'm not a fan of your error message (but, then again, anal wording is my specialty, so don't think I'm picking on you): I'd rename it to "That block title is already in use; please choose another." The goals here: The user may not remember all the previous titles he's used. Using "unique" starts forcing him to remember. We shouldn't do that. The user already knows he entered it - we don't have to repeat that to him. It's active, not passive (no use of "have"). Use a semi-colon, not a comma. It's much shorter and concise. ------------------------------------------------------------------------ April 9, 2005 - 00:27 : chx Attachment: http://drupal.org/files/issues/box_title.patch (1.49 KB) Why display any message at all? ------------------------------------------------------------------------ April 9, 2005 - 08:11 : Morbus Iff Displaying no message at all would only work if the user wasn't typing in ANY title whatsoever (since then we'd make one for them based on the date). But, if a user names a block "Users" one week, and then creates another block called "Users" three weeks later, than an whoopsidaisy error needs to be shown - we shouldn't modify the text randomly. ------------------------------------------------------------------------ April 9, 2005 - 09:10 : chx Well, let's discuss the main point: why shoiuld be the title unique? ------------------------------------------------------------------------ April 9, 2005 - 09:38 : Morbus Iff Are you asking why Drupal enforces them being unique, or why, visually and to the end-user, they should be unique? ------------------------------------------------------------------------ April 9, 2005 - 09:43 : chx I guess Drupal forces them 'cos for some reasons it is thought that for the users they should be unique. This is not the case, however. Yes, it's confusing if they are on the same page. But I can think on circumstances where they would not be on the same page, so the force from Drupal seems unnecessary. ------------------------------------------------------------------------ April 9, 2005 - 13:00 : robertDouglass agree with chx on the unique point. Like the functionality of adding html comments and timestamp (why timestamp? why not a block id?) if left blank if they must be uniqe. Would be in favor of making the visible title completely optional. Administrators have description to keep them separate on the admin screen. ------------------------------------------------------------------------ April 9, 2005 - 13:48 : Robin Monks Attachment: http://drupal.org/files/issues/drupal_0.patch (3.67 KB) This new patch no longer requires a unique value for title, and also checks to ensure the Block Description is not a duplicate or empty value. Big thanks go out to chx for assistance. Robin ------------------------------------------------------------------------ April 11, 2005 - 08:20 : Anonymous Shouldn't we add a test too to check info unicity ? ------------------------------------------------------------------------ April 11, 2005 - 08:38 : chx <?php if (empty($edit['info']) || db_num_rows(db_query("SELECT info FROM {boxes} WHERE info='%s'", $edit['info']))) { ?> To me, this seems like a check for info unicity... not to mention that the UNIQUE(info) DB constraint is not touched. ------------------------------------------------------------------------ April 11, 2005 - 08:46 : tostinni Ups, sorry for the anonymous and the message, I didn't saw this verification, I was only remembering block.module code. That's all fine for me.

1 0

[drupal-devel] [bug] queue.module doesn't record votes
by killes 11 Apr '05

11 Apr '05

Issue status update for http://drupal.org/node/20216 Project: Drupal Version: cvs Component: queue.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Kief Updated by: killes(a)www.drop.org -Status: active +Status: patch Attachment: http://drupal.org/files/issues/queue_2.patch (758 bytes) Ok, I made a patch as you indicated. Shouldn't harm at least. Should be applied to 4.6 and cvs. the term_node error is unrelated and addressed in a separate issue. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ April 9, 2005 - 16:54 : Kief Hello, I've been working on a test site using Drupal 4.6, I've just updated to the latest CVS as of a few hours ago, and have run the update.php. I've found that voting for nodes using the queue module doesn't work. The module attempts to insert the chosen option value submitted by the voting form, but this value is "+ 1", "+ 0", or "- 1", with spaces, and this doesn't work - no matter how you vote, the value recorded in the database is "0", so the node is never promoted. I've changed line 166 of queue.module to fix this (sorry for the lack of a proper patch): $votes = array('0' => t('neutral (+0)'), '1' => t('post it (+1)'), '-1' => t('dump it (-1)')); This records the votes properly in the database, however, I don't think this is a complete fix; after enough users have voted for a story to promote it, I get this error: user error: Duplicate entry '2-18' for key 1 query: INSERT INTO term_node (nid, tid) VALUES (18, 2) in C:\www\yabancikoy.com\docs\includes\database.mysql.inc on line 66. This module looks like it needs a bit of attention before it's released, I haven't got much time at the moment to poke into it more deeply, although if nobody else fixes it in the near future I will probably get around to it eventually since I really want to use this feature. Thanks, Kief ------------------------------------------------------------------------ April 9, 2005 - 20:09 : killes(a)www.drop.org Did you run update.php? ------------------------------------------------------------------------ April 11, 2005 - 09:19 : Kief Yes.

1 0

[drupal-devel] [bug] Patch for localized date in aggregator feed page
by carlosparamio 11 Apr '05

11 Apr '05

Issue status update for http://drupal.org/node/19109 Project: Drupal Version: cvs Component: aggregator.module Category: bug reports Priority: normal Assigned to: carlosparamio Reported by: carlosparamio Updated by: carlosparamio Status: patch Attachment: http://drupal.org/files/issues/aggregator_localized_date.path (407 bytes) Here is a patch for aggregator module so aggregator feed page shows dates with month name in localized version. carlosparamio

2 1