June 2005 - Development - lists.drupal.org

[drupal-devel] [task] Enhanced upload administration
by Junyor 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/25756 Project: Drupal Version: cvs Component: upload.module Category: tasks Priority: normal Assigned to: Junyor Reported by: Junyor Updated by: Junyor Status: patch Attachment: http://drupal.org/files/issues/drupal-4-6.upload.junyor.patch (4.84 KB) I've found the need to have some administration for file attachments. Here's a demo patch of some of the proposed added functionality. This functionality should easily allow users to get a list of the files they've uploaded, so they can get rid of old files if they reach their size limit. Changes: - Added an 'administer uploaded files' permission - Added admin/uploads and 'my uploads', which list uploaded files Planned changes: - statistics for the 'my uploads' and admin/uploads pages with total size of uploaded files and size limit - functionality to delete/rename files (using checkboxes to select multiple files) Please comment on code quality, current functionality, and planned functionality. Thanks. Patch applies to 4.6 and HEAD. Junyor

9 42

[drupal-devel] [feature] Dependency system to solve forum without comment problem
by chx 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/18447 Project: Drupal Version: cvs Component: system.module Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/depend.patch (3.22 KB) As discussed on the developer list. This was surprisingly easy. There is still an issue: t('The configuration options have been saved.') is displayed more than once if there is a dependency forced module switch on. I have tried something (you'll see) for some reason it does not work. Number of page reloads can be decreased if Drupal could be reinitialized after system_listing_save instead of redirecting but I doubt this would be feasible. Although I marked this is feature request, this is more a usability issue (for the forum-comment dependency) and as a side effect it is a useful feature, too (for any other module "bundles"). I want criticism! I'd like to get torn apart by wild animals. Heavy! Eaten by some squirrels. chx

14 45

[drupal-devel] [feature] Improved styling of autocomplete matches
by Thox 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/24932 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Thox Updated by: Thox Status: patch Attachment: http://drupal.org/files/issues/autocomplete_8.patch (1.39 KB) I'd like the autocomplete matches to be underlined (or styled in some way) so that users can see which part of the strings returned was actually matched. See Screenshot [1]. [1] http://photos14.flickr.com/19139302_0acb27f00d_o.png Thox

6 10

[drupal-devel] [task] Integrate primary links with menu navigation
by adrian 19 Sep '05

19 Sep '05

Issue status update for http://drupal.org/node/22215 Project: Drupal Version: 4.6.0 Component: theme system Category: tasks Priority: critical Assigned to: Anonymous Reported by: adrian Updated by: adrian Status: patch Attachment: http://drupal.org/files/issues/menu_patch.diff (7.58 KB) Here is the first version of the patch that uses the menu system to generate the primary and secondary navigational links. The navigation menu should by default be used as the source for the primary / secondary navigation (currently only in bluemarine, templates need to be modified to use this functionality). Furthermore, the css used sucks .. and we will need someone to write proper default css for us to make it at least presentable in the absence of theme css. The navlinks aren't really useful if there are more than 5 links in a menu, so admin/ looks utterly horrible. This code is copied and adjusted from Bér's primary links module, and Adrian Simmons cleaned up the CSS a bit. Bér didn't have any css with the module, so I had to rip it from his webschuur.com site. adrian

7 12

[drupal-devel] [task] Introduce theme wrapper, as discussed on the Sprint
by Bèr Kessels 18 Sep '05

18 Sep '05

Issue status update for http://drupal.org/node/23584 Project: Drupal Version: cvs Component: theme system Category: tasks Priority: normal Assigned to: Bèr Kessels Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch Attachment: http://drupal.org/files/issues/theme_wrapper.patch (1.23 KB) I finally got around this. On the useability sprint inAntwerp we agreed that theme_box is: 1) not flexible, 2) underused 3) very powerfull for themers, consistancy and developers if it has enough information. This patch introduces such a function, called theme_wrapper. Theme('wrapper') should be called EVERYWHERE where we now have hardcoded spans and divs, only to be able to add a class or ID to a (part of -) a page. >From the notes: " ** HTML themed wrapper ** Currently, we use a theme_box to wrap parts of pages in HTML. This should be extended, but most of, all, get better CSS support. Thus a wrapper should be introduced, one that should replace theme_box. This theme_wrapper can and/or will get an ID and a class. * Both class and ID should be passed as elements, so that it is up to the developers to pqss correct classes and Ids; * Both the ID and class are required. (?) * Discuss whether or not they are required. **List of classes.** When passing a class, the developer should be encourqged to choose an existing class, instead of inventing new ones for every wrapper. This will be achieved by a list of standard classes, that will be available in drupal.css. Think of classes such as “3-col-left”, “3-col-center” and “3-col-right”, for wrappers that will make content in a 3 columned way. This could be used, for example in a directory.module to present three directories next to one another. TODO: Create a standard set of classes, that can, and should be, (re-) used by developers. ** Ids** Ids should be unique on a page, thus the developer must make sure, he or she does not use an ID that is already existing on the page where his or her HTML will be rendered. But just like with the classees, we should avoid a wildgrowth of ids. Thus, good guidelines, including lists of examples, lust be written. TODO: Create guidelines for ID-ing elements in Drupal. " Bèr Kessels

8 40

[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] 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] [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

[drupal-devel] [feature] Add create_child grant type in node_access system
by clydefrog 11 Sep '05

11 Sep '05

Issue status update for http://drupal.org/node/20890 Project: Drupal Version: cvs Component: node system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: clydefrog Updated by: clydefrog Status: patch Attachment: http://drupal.org/files/issues/access_child_page.patch (3.26 KB) This patch makes it possible to restrict which nodes can be used as parents when editing child book pages. Here's a quick summary of the changes: Add grant_create_child column to node_access page. Set grant_create_child to 1 in the default nid = 0 row. Pass array('op' => 'create_child') to db_rewrite_sql() in book_toc(). Modify node_db_rewrite_sql() so that the "$op" argument is used in _node_access_where_sql() Generalize node_access_view_all_nodes() to node_access_all_nodes($op) I'm not sure I've covered all the bases. In particular, the "add child page" link still appears on all book pages. Also, there is nothing stopping a clueful user from passing an arbitrary parent nid when submitting. But shouldn't those be the responsibility of the particular node_access module? Thanks for considering this patch. An aside: The attached patch was made with "diff -ru". Is it acceptable to use "cvs diff -u" as well? clydefrog

3 5

[drupal-devel] [feature] OPML Import for Aggregator
by arnabdotorg 10 Sep '05

10 Sep '05

Project: Drupal Version: cvs Component: aggregator.module Category: feature requests Priority: normal Assigned to: arnabdotorg Reported by: arnabdotorg Updated by: arnabdotorg Status: patch Attachment: http://drupal.org/files/issues/import_opml.patch (3.96 KB) The aggregator supports OPML export for all feeds, but not import. This patch enables import of OPML lists, allowing people to import lists of RSS feeds they've already assembled in another RSS app. Demo: http://arnab.drupaldevs.org/aggregator Patch: http://arnab.drupaldevs.org/tmp/import_opml.patch arnabdotorg -- View: http://drupal.org/node/16282 Edit: http://drupal.org/project/comments/add/16282

5 6