June 2005 - Development - lists.drupal.org

[drupal-devel] primar navigation
by Bèr Kessels 10 Jun '05

10 Jun '05

I have to abandon this, I spent way too much time on this already, but have trouble with the bordering levels. I simply do not manage to get the proper iterations of the -very complex- menu array. Is there anyone who has enough advanced array knowledge, so that he/she can finish this? If not,we will not have more advanced pirimary menus in core for 4.7. You can find my works in my sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/ber/primary_link… And the -working- module: http://cvs.drupal.org/viewcvs/drupal/contributions/modules/primary_links/ The issue is at http://drupal.org/node/22215 Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

2 1

[drupal-devel] Moving on
by Chris Messina 10 Jun '05

10 Jun '05

Hi all, After much deliberation and careful consideration, I have decided to move on from CivicSpace at the end of June. Though there were many, many things that weighed in to my decision, the clincher came last week when I received an offer for a senior position within Round Two. The position puts me in a strategic position to advance the culture of open source as one of my duties will be to act as an ambassador of open source to other projects, organizations, officials and wider audiences, extending the work I started with Spread Firefox. I am very excited about this part of my duties as it will enable me to create allies and forge the kind of networks that open source will need to become the dominant development standard throughout the world (yes, big goals!). Indeed, I see this new opportunity for me as both a necessary step forward for myself as well my work on CivicSpace. As such, I have every intention of maintaining a close relationship with CivicSpace and making sure that my work will continue to benefit the CivicSpace and Drupal communities. I will complete my work on the next CivicSpace release to ensure that my work will not prevent CivicSpace from moving into the next chapter of its story with anything less than a clean slate. Though I won't directly experience it, I am thrilled that Kieran has joined the team and think he will lead CivicSpace to new heights; CivicSpace is very fortunate to have him! If you have any questions or comments, please feel free to let me know. I will continue to be available to discuss CivicSpace, interface and other matters. It's truly been a privilege to work for CivicSpace and to have made as many good friends as I have. I continue to believe that the CivicSpace concept will continue to grow, mature and empower communities the world over. Chris

4 3

[drupal-devel] [feature] Profile field visiblity should vary by role
by ejort 10 Jun '05

10 Jun '05

Issue status update for http://drupal.org/node/14149 Project: Drupal Version: cvs Component: profile.module Category: feature requests Priority: normal Assigned to: ejort Reported by: sushi76 Updated by: ejort Status: patch Yes, unfortunately it can add a large number of permissions to the permissions page. I did consider trying to place the permission selections on each fields edit page instead (similar to the visibility settings), but as a certain eminent author recently wrote* [1]: "please use *only* the permissions page to set permissions, and do not create new permissions-alike settings in any configuration pages " :-) I think that the PROFILE_PRIVATE and PROFILE_HIDDEN (and the PROFILE_PUBLIC_*) settings are currently doing just that, implementing an alternate permissions system which addresses a few use cases, but is ultimately not particularly flexible. Is there any chance that the permissions sections can benefit from some collapsible goodness to alleviate the flooding? I think it's a shame to reduce the systems flexibility because it may create 'too many' permissions settings, especially as it is generally a set once and forget proposition. Perhaps we should look at the underlying UI problem? *That would be Bér :-) [1] http://drupal.org/node/22565#comment-32248 ejort Previous comments: ------------------------------------------------------------------------ December 10, 2004 - 05:38 : sushi76 Currently there are only these three Options Private field, content only available to privileged users. (Admin users) Public field, content shown on profile page but not used on member list pages. (Everyone, but not in the member list) Public field, content shown on profile page and on member list pages. (Everyone, everywhere) It should be possible to set the visibilty of profile fields by user roles. ------------------------------------------------------------------------ March 7, 2005 - 07:40 : tulula I agree! If visibility is set by roles OR if the option is left up to the user to display their info at their discretion vs Admin at level of setting up profile fields. ------------------------------------------------------------------------ June 6, 2005 - 16:03 : ejort I agree that it should be possible to set visibility per role. There is profile data on my site that I want my organisation's committee members to see, but nobody else, there's information that I want only authenticated users to see, but not anonymous users etc. More than that, I think we should be able to set field editability by role also. There is data on my site that only certain people should be able to edit. If we get to this point then this would be a superset of the functionality discussed in the PROFILE_HIDDEN updates [2] thread, but would be much more flexible. [2] http://drupal.org/node/21219 ------------------------------------------------------------------------ June 10, 2005 - 19:07 : ejort Attachment: http://drupal.org/files/issues/profile.module.role_based_field_permissions.… (12.97 KB) Hi, Here's a patch which implements role based edit / access permissions for profile fields. It allows you to give permissions to each role (and for each field) to: * access a field (for all accounts) * access a field for your own account * edit a field for your account Users with permission 'administer users' can access / edit all fields, and users must have enough permission to edit/access a profile for these extra permissions to come into effect. I believe this allows for more flexibility than the existing profile.module method of PROFILE_PRIVATE and in HEAD PROFILE_HIDDEN. You can eg: * hide some fields from anonymous users, while allowing other roles to still view that info * have fields viewable by only the admin and user who owns the account (like PROFILE_PRIVATE * have fields viewable by some roles, but only editable by the admin * have fields hidden from all except the admin, and editable only by the admin * it will make you more attractive to the opposite sex etc. I'm developing this because I need it for one of my sites, hence, unfortunately this patch is against the 4.6 profile.module. If people think this is a valuable feature for HEAD I can roll a patch against that. Cheers, Eric ------------------------------------------------------------------------ June 10, 2005 - 20:13 : Bèr Kessels I am not too sure about this. A typical profile contains between five and 10 fields, but twenty fields is not unheard of. This patch will flood the permissions screen unnneccesary. I would opt for the hard way: An advanced profile module, or CRM module, or so. hat module could implemen,t all sorts of advanced levelled permissions. In order to maintain a high level of usability in core, we should try to minimize options and checkboxes. I know from flexinode, which adds similar dynamic permissions, that the interface for permissions is really not up to this big amount of permissions. I really think such things should not be in core. Buty that all said, it /is/ a handy feature :)

1 0

[drupal-devel] [feature] Profile field visiblity should vary by role
by Bèr Kessels 10 Jun '05

10 Jun '05

Issue status update for http://drupal.org/node/14149 Project: Drupal Version: cvs Component: profile.module Category: feature requests Priority: normal Assigned to: ejort Reported by: sushi76 Updated by: Bèr Kessels Status: patch I am not too sure about this. A typical profile contains between five and 10 fields, but twenty fields is not unheard of. This patch will flood the permissions screen unnneccesary. I would opt for the hard way: An advanced profile module, or CRM module, or so. hat module could implemen,t all sorts of advanced levelled permissions. In order to maintain a high level of usability in core, we should try to minimize options and checkboxes. I know from flexinode, which adds similar dynamic permissions, that the interface for permissions is really not up to this big amount of permissions. I really think such things should not be in core. Buty that all said, it /is/ a handy feature :) Bèr Kessels Previous comments: ------------------------------------------------------------------------ December 9, 2004 - 19:38 : sushi76 Currently there are only these three Options Private field, content only available to privileged users. (Admin users) Public field, content shown on profile page but not used on member list pages. (Everyone, but not in the member list) Public field, content shown on profile page and on member list pages. (Everyone, everywhere) It should be possible to set the visibilty of profile fields by user roles. ------------------------------------------------------------------------ March 6, 2005 - 21:40 : tulula I agree! If visibility is set by roles OR if the option is left up to the user to display their info at their discretion vs Admin at level of setting up profile fields. ------------------------------------------------------------------------ June 6, 2005 - 06:03 : ejort I agree that it should be possible to set visibility per role. There is profile data on my site that I want my organisation's committee members to see, but nobody else, there's information that I want only authenticated users to see, but not anonymous users etc. More than that, I think we should be able to set field editability by role also. There is data on my site that only certain people should be able to edit. If we get to this point then this would be a superset of the functionality discussed in the PROFILE_HIDDEN updates [1] thread, but would be much more flexible. [1] http://drupal.org/node/21219 ------------------------------------------------------------------------ June 10, 2005 - 09:07 : ejort Attachment: http://drupal.org/files/issues/profile.module.role_based_field_permissions.… (12.97 KB) Hi, Here's a patch which implements role based edit / access permissions for profile fields. It allows you to give permissions to each role (and for each field) to: * access a field (for all accounts) * access a field for your own account * edit a field for your account Users with permission 'administer users' can access / edit all fields, and users must have enough permission to edit/access a profile for these extra permissions to come into effect. I believe this allows for more flexibility than the existing profile.module method of PROFILE_PRIVATE and in HEAD PROFILE_HIDDEN. You can eg: * hide some fields from anonymous users, while allowing other roles to still view that info * have fields viewable by only the admin and user who owns the account (like PROFILE_PRIVATE * have fields viewable by some roles, but only editable by the admin * have fields hidden from all except the admin, and editable only by the admin * it will make you more attractive to the opposite sex etc. I'm developing this because I need it for one of my sites, hence, unfortunately this patch is against the 4.6 profile.module. If people think this is a valuable feature for HEAD I can roll a patch against that. Cheers, Eric

1 0

[drupal-devel] [feature] Profile field visiblity should vary by role
by ejort 10 Jun '05

10 Jun '05

Issue status update for http://drupal.org/node/14149 Project: Drupal Version: cvs Component: profile.module Category: feature requests Priority: normal -Assigned to: Anonymous +Assigned to: ejort Reported by: sushi76 Updated by: ejort -Status: active +Status: patch Attachment: http://drupal.org/files/issues/profile.module.role_based_field_permissions.… (12.97 KB) Hi, Here's a patch which implements role based edit / access permissions for profile fields. It allows you to give permissions to each role (and for each field) to: * access a field (for all accounts) * access a field for your own account * edit a field for your account Users with permission 'administer users' can access / edit all fields, and users must have enough permission to edit/access a profile for these extra permissions to come into effect. I believe this allows for more flexibility than the existing profile.module method of PROFILE_PRIVATE and in HEAD PROFILE_HIDDEN. You can eg: * hide some fields from anonymous users, while allowing other roles to still view that info * have fields viewable by only the admin and user who owns the account (like PROFILE_PRIVATE * have fields viewable by some roles, but only editable by the admin * have fields hidden from all except the admin, and editable only by the admin * it will make you more attractive to the opposite sex etc. I'm developing this because I need it for one of my sites, hence, unfortunately this patch is against the 4.6 profile.module. If people think this is a valuable feature for HEAD I can roll a patch against that. Cheers, Eric ejort Previous comments: ------------------------------------------------------------------------ December 10, 2004 - 05:38 : sushi76 Currently there are only these three Options Private field, content only available to privileged users. (Admin users) Public field, content shown on profile page but not used on member list pages. (Everyone, but not in the member list) Public field, content shown on profile page and on member list pages. (Everyone, everywhere) It should be possible to set the visibilty of profile fields by user roles. ------------------------------------------------------------------------ March 7, 2005 - 07:40 : tulula I agree! If visibility is set by roles OR if the option is left up to the user to display their info at their discretion vs Admin at level of setting up profile fields. ------------------------------------------------------------------------ June 6, 2005 - 16:03 : ejort I agree that it should be possible to set visibility per role. There is profile data on my site that I want my organisation's committee members to see, but nobody else, there's information that I want only authenticated users to see, but not anonymous users etc. More than that, I think we should be able to set field editability by role also. There is data on my site that only certain people should be able to edit. If we get to this point then this would be a superset of the functionality discussed in the PROFILE_HIDDEN updates [1] thread, but would be much more flexible. [1] http://drupal.org/node/21219

1 0

[drupal-devel] [bug] Statistic information about node reads is shown to unprivileged users
by frjo 10 Jun '05

10 Jun '05

Issue status update for http://drupal.org/node/22565 Project: Drupal Version: cvs Component: statistics.module Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: massabob Updated by: frjo Status: patch +1 I have implemented the patch authstats_2.patch on my site running Drupal 4.6.1 and it works well. frjo Previous comments: ------------------------------------------------------------------------ May 11, 2005 - 08:51 : massabob Information about '%count reads' in node's footer is shown to unprivileged users. I suggest that function statistics_link in statistics.module should be corrected in this way: // Original function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0)) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } // Fixed function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0) && user_access('display statistics')) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } The only change is in "&& user_access('display statistics')" on line 98. ------------------------------------------------------------------------ May 27, 2005 - 02:44 : rbarreca Should read user_access('access statistics') not user_access('display statistics'). ------------------------------------------------------------------------ May 27, 2005 - 12:19 : Robin Monks Attachment: http://drupal.org/files/issues/user.access.stats.patch (730 bytes) And here that is in patch form. Robin ------------------------------------------------------------------------ June 1, 2005 - 05:09 : Steven I'm not sure about this patch: often, read counts are shown directly on the site. But if the permission for viewing the counts is the same as the permission for accessing the administrator's detailed logs, then you wouldn't give that to everyone. There is already an option to choose whether counts are displayed. Perhaps we could change that to "No" "For priviledged users" "For everyone". In last case it acts like it is now, it the second case it requires "access statistics" permission. What do you think? ------------------------------------------------------------------------ June 1, 2005 - 15:13 : Robin Monks Sounds good to me. I'll try to code something up for this. Robin ------------------------------------------------------------------------ June 9, 2005 - 14:55 : Robin Monks Attachment: http://drupal.org/files/issues/authstats.patch (2.26 KB) Here is the patch. Uses a switch to choose between signed in users, all users, users with permissions or noone. Robin ------------------------------------------------------------------------ June 9, 2005 - 15:08 : Robin Monks I tested this patch with various settings on my local install and it worked fine. Robin ------------------------------------------------------------------------ June 9, 2005 - 17:30 : Bèr Kessels Is there a reason why you check for $user->uid? Whaen someone has "access statistics" set to anonymous users, your check for $user->uid will override taht settings. Not good IMO. <?php $group .= form_radios(t('Display counter values'), 'statistics_display_counter', variable_get('statistics_display_counter', 0), array('1' => t('For all users'), '2' => t('For authenticated users'), '3' => t('For priviledged users'), '0' => t('Disabled')), t('Display how many times given content has been viewed.')); ?> is very inconsistent. please use *only* the permissions page to set permissions, and do not create new permissions-alike settings in any configuration pages. I would say a simple check for user_access('access statistics') will do the trick ------------------------------------------------------------------------ June 9, 2005 - 17:32 : Bèr Kessels sorry, i meant to say user_access('access statistics counter'), not user_access('access statistics'). We already have "access statistics'" an additional "access statistics counter" for showing users the counter should work Ber ------------------------------------------------------------------------ June 9, 2005 - 17:49 : Robin Monks Attachment: http://drupal.org/files/issues/statistics.module (23.1 KB) OK, here is a patch to that end... Robin ------------------------------------------------------------------------ June 9, 2005 - 18:00 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_0.patch (1 KB) Um, let's just pretend I didn't just upload the entire stats module. OK? OK! Robin ------------------------------------------------------------------------ June 9, 2005 - 18:05 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_1.patch (1.06 KB) Hotfix. Robin ------------------------------------------------------------------------ June 9, 2005 - 18:11 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_2.patch (1.11 KB) Hopefuly the final version. Thanks to chx and berkes for pulling it apart ;-) Robin ------------------------------------------------------------------------ June 9, 2005 - 18:21 : Bèr Kessels +1 for this patch. it adds functionality, but does not add clutter nor any config options.

1 0

[drupal-devel] [bug] Theme div and span
by Robin Monks 10 Jun '05

10 Jun '05

Issue status update for http://drupal.org/node/24684 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: Robin Monks Updated by: Robin Monks Status: patch Attachment: http://drupal.org/files/issues/themedivspan.patch (1.19 KB) This patch adds support for theme_div and theme_span. I've tested this on CVS and it works fine. Darix is also doing some work on this in modules. Robin Robin Monks

2 3

[drupal-devel] new CVS accounts
by Dries Buytaert 09 Jun '05

09 Jun '05

Hello world, I approved a bunch of CVS accounts. Please welcome our new contributors, and assist them as necessary. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] [bug] Statistic information about node reads is shown to unprivileged users
by Bèr Kessels 09 Jun '05

09 Jun '05

Issue status update for http://drupal.org/node/22565 Project: Drupal Version: cvs Component: statistics.module Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: massabob Updated by: Bèr Kessels Status: patch +1 for this patch. it adds functionality, but does not add clutter nor any config options. Bèr Kessels Previous comments: ------------------------------------------------------------------------ May 11, 2005 - 08:51 : massabob Information about '%count reads' in node's footer is shown to unprivileged users. I suggest that function statistics_link in statistics.module should be corrected in this way: // Original function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0)) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } // Fixed function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0) && user_access('display statistics')) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } The only change is in "&& user_access('display statistics')" on line 98. ------------------------------------------------------------------------ May 27, 2005 - 02:44 : rbarreca Should read user_access('access statistics') not user_access('display statistics'). ------------------------------------------------------------------------ May 27, 2005 - 12:19 : Robin Monks Attachment: http://drupal.org/files/issues/user.access.stats.patch (730 bytes) And here that is in patch form. Robin ------------------------------------------------------------------------ June 1, 2005 - 05:09 : Steven I'm not sure about this patch: often, read counts are shown directly on the site. But if the permission for viewing the counts is the same as the permission for accessing the administrator's detailed logs, then you wouldn't give that to everyone. There is already an option to choose whether counts are displayed. Perhaps we could change that to "No" "For priviledged users" "For everyone". In last case it acts like it is now, it the second case it requires "access statistics" permission. What do you think? ------------------------------------------------------------------------ June 1, 2005 - 15:13 : Robin Monks Sounds good to me. I'll try to code something up for this. Robin ------------------------------------------------------------------------ June 9, 2005 - 14:55 : Robin Monks Attachment: http://drupal.org/files/issues/authstats.patch (2.26 KB) Here is the patch. Uses a switch to choose between signed in users, all users, users with permissions or noone. Robin ------------------------------------------------------------------------ June 9, 2005 - 15:08 : Robin Monks I tested this patch with various settings on my local install and it worked fine. Robin ------------------------------------------------------------------------ June 9, 2005 - 17:30 : Bèr Kessels Is there a reason why you check for $user->uid? Whaen someone has "access statistics" set to anonymous users, your check for $user->uid will override taht settings. Not good IMO. <?php $group .= form_radios(t('Display counter values'), 'statistics_display_counter', variable_get('statistics_display_counter', 0), array('1' => t('For all users'), '2' => t('For authenticated users'), '3' => t('For priviledged users'), '0' => t('Disabled')), t('Display how many times given content has been viewed.')); ?> is very inconsistent. please use *only* the permissions page to set permissions, and do not create new permissions-alike settings in any configuration pages. I would say a simple check for user_access('access statistics') will do the trick ------------------------------------------------------------------------ June 9, 2005 - 17:32 : Bèr Kessels sorry, i meant to say user_access('access statistics counter'), not user_access('access statistics'). We already have "access statistics'" an additional "access statistics counter" for showing users the counter should work Ber ------------------------------------------------------------------------ June 9, 2005 - 17:49 : Robin Monks Attachment: http://drupal.org/files/issues/statistics.module (23.1 KB) OK, here is a patch to that end... Robin ------------------------------------------------------------------------ June 9, 2005 - 18:00 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_0.patch (1 KB) Um, let's just pretend I didn't just upload the entire stats module. OK? OK! Robin ------------------------------------------------------------------------ June 9, 2005 - 18:05 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_1.patch (1.06 KB) Hotfix. Robin ------------------------------------------------------------------------ June 9, 2005 - 18:11 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_2.patch (1.11 KB) Hopefuly the final version. Thanks to chx and berkes for pulling it apart ;-) Robin

1 0

[drupal-devel] [bug] Statistic information about node reads is shown to unprivileged users
by Robin Monks 09 Jun '05

09 Jun '05

Issue status update for http://drupal.org/node/22565 Project: Drupal Version: cvs Component: statistics.module Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: massabob Updated by: Robin Monks Status: patch Attachment: http://drupal.org/files/issues/authstats_2.patch (1.11 KB) Hopefuly the final version. Thanks to chx and berkes for pulling it apart ;-) Robin Robin Monks Previous comments: ------------------------------------------------------------------------ May 11, 2005 - 07:51 : massabob Information about '%count reads' in node's footer is shown to unprivileged users. I suggest that function statistics_link in statistics.module should be corrected in this way: // Original function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0)) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } // Fixed function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0) && user_access('display statistics')) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } The only change is in "&& user_access('display statistics')" on line 98. ------------------------------------------------------------------------ May 27, 2005 - 01:44 : rbarreca Should read user_access('access statistics') not user_access('display statistics'). ------------------------------------------------------------------------ May 27, 2005 - 11:19 : Robin Monks Attachment: http://drupal.org/files/issues/user.access.stats.patch (730 bytes) And here that is in patch form. Robin ------------------------------------------------------------------------ June 1, 2005 - 04:09 : Steven I'm not sure about this patch: often, read counts are shown directly on the site. But if the permission for viewing the counts is the same as the permission for accessing the administrator's detailed logs, then you wouldn't give that to everyone. There is already an option to choose whether counts are displayed. Perhaps we could change that to "No" "For priviledged users" "For everyone". In last case it acts like it is now, it the second case it requires "access statistics" permission. What do you think? ------------------------------------------------------------------------ June 1, 2005 - 14:13 : Robin Monks Sounds good to me. I'll try to code something up for this. Robin ------------------------------------------------------------------------ June 9, 2005 - 13:55 : Robin Monks Attachment: http://drupal.org/files/issues/authstats.patch (2.26 KB) Here is the patch. Uses a switch to choose between signed in users, all users, users with permissions or noone. Robin ------------------------------------------------------------------------ June 9, 2005 - 14:08 : Robin Monks I tested this patch with various settings on my local install and it worked fine. Robin ------------------------------------------------------------------------ June 9, 2005 - 16:30 : Bèr Kessels Is there a reason why you check for $user->uid? Whaen someone has "access statistics" set to anonymous users, your check for $user->uid will override taht settings. Not good IMO. <?php $group .= form_radios(t('Display counter values'), 'statistics_display_counter', variable_get('statistics_display_counter', 0), array('1' => t('For all users'), '2' => t('For authenticated users'), '3' => t('For priviledged users'), '0' => t('Disabled')), t('Display how many times given content has been viewed.')); ?> is very inconsistent. please use *only* the permissions page to set permissions, and do not create new permissions-alike settings in any configuration pages. I would say a simple check for user_access('access statistics') will do the trick ------------------------------------------------------------------------ June 9, 2005 - 16:32 : Bèr Kessels sorry, i meant to say user_access('access statistics counter'), not user_access('access statistics'). We already have "access statistics'" an additional "access statistics counter" for showing users the counter should work Ber ------------------------------------------------------------------------ June 9, 2005 - 16:49 : Robin Monks Attachment: http://drupal.org/files/issues/statistics.module (23.1 KB) OK, here is a patch to that end... Robin ------------------------------------------------------------------------ June 9, 2005 - 17:00 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_0.patch (1 KB) Um, let's just pretend I didn't just upload the entire stats module. OK? OK! Robin ------------------------------------------------------------------------ June 9, 2005 - 17:05 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_1.patch (1.06 KB) Hotfix. Robin

1 0