August 2005 - Development - lists.drupal.org

[drupal-devel] [feature] Auto-expand navigation menu options on mouseover
by nedjo 17 Sep '05

17 Sep '05

Issue status update for http://drupal.org/node/29551 Post a follow up: http://drupal.org/project/comments/add/29551 Project: Drupal Version: cvs Component: menu system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: nedjo Updated by: nedjo Status: patch (code needs review) Attachment: http://drupal.org/files/issues/expandable_menu.patch (2.16 KB) One or more unneeded page loads are often required to bring up the desired page through the navigation menu (e.g., administer > settings > content types). Using CSS, this patch introduces automatically expanding menu options. E.g., holding the mouse over "create content" will dynamically expand the menu, revealing the available options ("page", "story", etc.). Issues & questions: * Is this a desired behaviour? * Page loads are slightly larger, since they include hidden menu portions. * Not supported by, e.g., Internet Explorer due to CSS bugs. Downgrades cleanly, but means that functionality is not uniform across browsers. A js IE fix is available, see e.g., http://www.alistapart.com/articles/dropdowns/ but it's a big ugly. * Display is a bit jumpy. Slideouts or slowed transitions might be nice, but would I assume require javascript. * Introduced as the default behaviour, not as an option. Should this be a configuration option instead? The approach is based on suggestions and code [1] for the taxonomy_context module by eferraiuolo [2]. [1] http://drupal.org/node/29074 [2] http://drupal.org/user/24218\" title=\"View user profile. nedjo

9 21

[drupal-devel] [feature] Mark All Read functionality
by pyromanfo 16 Sep '05

16 Sep '05

Issue status update for http://drupal.org/node/24883 Project: Drupal Version: 4.6.0 Component: node system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: pyromanfo Updated by: pyromanfo Status: patch Attachment: http://drupal.org/files/issues/mark_read.patch (2.25 KB) This patch adds URLs in the form of 'node/readall' and 'node/readall/$tid' that mark all nodes, or all nodes within a given category, as read by the current user. This also adds "mark all read" and "mark this forum read" links to the forums. pyromanfo

3 2

[drupal-devel] [feature] admin/access hover help - little patch, big help
by jjeff 15 Sep '05

15 Sep '05

Issue status update for http://drupal.org/node/28301 Post a follow up: http://drupal.org/project/comments/add/28301 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: jjeff Reported by: jjeff Updated by: jjeff Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/admin.access.hover.help.patch (799 bytes) Here's a patch that adds a 'title' tag to all of the checkboxes in the admin/access grid. When you roll over the checkboxes in most browsers a tool-tip box will pop up with information about what each checkbox is. Examples: "anonymous user : edit own blog" "authenticated user : post comments" "admin : administer filters" On a site with many roles and many modules, it becomes very easy to scroll away from the table headers, so this is essential for figuring out what you're clicking. It doesn't solve all of the admin/access page usability problems, but it does make the page a lot more usable. Little patch. Big help. -Jeff jjeff

5 8

[drupal-devel] [feature] New field type for profile: taxonomy
by wiz 15 Sep '05

15 Sep '05

Issue status update for http://drupal.org/node/19014 Project: Drupal Version: cvs Component: profile.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: wiz Updated by: wiz Status: patch Attachment: http://drupal.org/files/issues/profile-taxonomy.patch (3.87 KB) A new type of field in the profile: taxonomy, useful for a field to select zero or more terms from a vocabulary. This works like the type "selection" but multiple selection is possible, and the list of choices comes from a taxonomy. Unfortunately there is no field in the table profile_fields to store single/multiple selection - which would be nice for the type "selection", too. The selection is stored in a new table (profile_values_term) additionally to the column profile_values.value. This allows for easy processing of the selection the user made. I have not defined any indexes on this new table, which possibly would be required for large data sets. It has a small bug: when nothing is selected, it will automatically select the first entry. The fix would probably have to modify _taxonomy_term_select in taxonomy.module. wiz

2 2

[drupal-devel] [task] Use thead and tbody in theme_table()
by drumm 15 Sep '05

15 Sep '05

Issue status update for http://drupal.org/node/28777 Post a follow up: http://drupal.org/project/comments/add/28777 Project: Drupal Version: cvs Component: theme system Category: tasks Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch (code needs review) Attachment: http://drupal.org/files/issues/theme.inc_2.diff (1.26 KB) For extra accessibility and semanticity we should throw in a thead tag if there is a header row and always put in a tbody tag. drumm

4 7

[drupal-devel] [bug] Using tabindex in user login form
by tostinni 13 Sep '05

13 Sep '05

Issue status update for http://drupal.org/node/29060 Post a follow up: http://drupal.org/project/comments/add/29060 Project: Drupal Version: 4.6.0 Component: user.module Category: bug reports Priority: minor Assigned to: Anonymous Reported by: tostinni Updated by: tostinni Status: patch (code needs review) Attachment: http://drupal.org/files/issues/user_tabindex.patch (1.75 KB) When the drupal module is activated, when you go to /user to log in, you have a link that appear to Drupal.org Enter your drupal username, or an ID from one of our affiliates: Drupal., so when you use "tab" to switch from one input to another, you go in order : - username input - Drupal link - password input So I think the logic is biased as you're supposed to reach first username, then password and end by the submit button. This patch add tabindex to input fields to force this behaviour. tostinni

5 5

[drupal-devel] [bug] Password reset page - username and e-mail checks don't work
by kumo 13 Sep '05

13 Sep '05

Issue status update for http://drupal.org/node/29548 Post a follow up: http://drupal.org/project/comments/add/29548 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: kumo Updated by: kumo Status: patch (code needs review) Attachment: http://drupal.org/files/issues/user_pass_reset_checks.patch (1.73 KB) On the password reset page, if a user enters a non-existant username or e-mail address, the 'Further instructions have been sent to your e-mail address.' message is shown The attached patch fixes this issue. It also removes an extraneous message shown if no username or password is given or when the unrecognised username or e-mail address messages are shown. kumo

4 8

[drupal-devel] [bug] node revisions should only be viewable by admins
by killes 13 Sep '05

13 Sep '05

Issue status update for http://drupal.org/node/30098 Post a follow up: http://drupal.org/project/comments/add/30098 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: killes(a)www.drop.org Updated by: killes(a)www.drop.org Status: patch (code needs review) Attachment: http://drupal.org/files/issues/node_rev.patch (1.27 KB) With or without the revisions patch, every user who can access content can access old revisions. I think this is a bug because why would you need to see old revisions if you cannot change them or make them the current revision? The attached patch fixes this and lets only users with "administer nodes" permission see old revs as you need this permission to change revisiosn to be the current one. One might make a case for introducing new "view revisions" and "set revisions" perms. You woud need those if you wanted to mimic a wiki with Drupal. killes(a)www.drop.org

9 25

[drupal-devel] Re: [contributions:MegaGrunt] /modules/publication publication.module publication.mysql readme.txt
by Dries Buytaert 12 Sep '05

12 Sep '05

On 19 Aug 2005, at 02:04, drupal-cvs(a)drupal.org wrote: > User: MegaGrunt Branch: HEAD Date: Fri, 19 Aug 2005 00:04:08 > +0000 > > Added files: > /modules/publication publication.module publication.mysql readme.txt > > Log message: > Handles data, logic, and UI of publication(s). > > Component module which provides service to other modules. - This does mean what? I guess I'll have to read the readme.txt (which should be README.txt really). - I'm afraid the subtle differences in your modules' names are somewhat confusing: + There is already a scheduleR module. How does your schedule module differ? + There is already a subscription module. How does your subscribe module differ? Doesn't JonBob have a subscribe module too? (I want a subscription.module in core (e-mail notifications) but don't want to ship both a subscribe and subscription module. I want a single-file module with or without additional .inc files.) - What other modules are going to re-use the scheduler and subscribe modules? - The e-commerce module groups its modules in modules/ecommerce. In general I like that better, because it makes for one well-defined project. -- Dries Buytaert :: http://www.buytaert.net/

4 3

[drupal-devel] [feature] More granular user management permissions
by budda 11 Sep '05

11 Sep '05

Issue status update for http://drupal.org/node/25530 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: budda Updated by: budda Status: patch Attachment: http://drupal.org/files/issues/accesscontrol.patch (3.48 KB) When a user role is granted 'administer users' permission this allows them to not only edit any users profile, but also amend the access control list, even for their own role. This means a moderator could actually increase their own permissions to enable further access to Drupal site settings. To prevent this I have split the user module permissions further to provide a new permission setting for each role - "administer permissions". Enabling this permission for any role will provide the user with access to the "access control" pages and functionality. Patch attached to add additional permission and change menu access checks as needed. budda

9 11