Posted by hefox on September 24, 2009 at 1:36pm
6 followers
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | contact.module |
| Category: | bug report |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | needs backport to D6, Needs tests |
Issue Summary
The contact form of blocked users is still valid, but in general they can't sign on and thus can't disable their contact form.
I'd just change it
<?php
function _contact_user_tab_access($account) {
global $user;
if (!isset($account->contact) || empty($account->status)) { // here
$account->contact = FALSE;
}
return
$account && $user->uid &&
(
($user->uid != $account->uid && $account->contact) ||
user_access('administer users')
);
}
?>So administers can still use the blocked users contact form.
Another way to do it
<?php
function _contact_user_tab_access($account) {
global $user;
if (!isset($account->contact) || (empty($account->status) && empty(variable_get('blocked_contact',0)))) { // here
$account->contact = FALSE;
}
return
$account && $user->uid &&
(
($user->uid != $account->uid && $account->contact) ||
user_access('administer users')
);
}
?>with the blocked_contact being a setting somewhere to allow the current workflow, ie contact by anyone with contact permission of blocked user's profiles.
Also, this is also likely an issue with 7.x but I don't have a 7.x dev box or anything so can't see atm, thus I set it to 6.14. though.. http://api.drupal.org/api/function/_contact_personal_tab_access/7 . It's also not part of the last adding permission for personal contact form patch, ie. http://drupal.org/files/issues/58224.031.patch (http://drupal.org/node/58224).
I can make a patch but it'd be against 6-1.4.
Hope this isn't a duplicate issue; Searched 6.x&7.x for contact.module on words 'banned' and 'blocked'.
Comments
#1
Oops u.u;;;
#2
Seems valid, although users with admin permissions should still be able to contact them. Bumping to a bug report and adding to my D7 list to get fixed there first.
#3
=)
(BTW, I have no idea if this has been fixed on d7 or if there's issues, but two related issues in d6
the contact forum enable checkbox on user_profile_form contains a link to user's contact forum despite not having access without 'administer users' to it, ie. $user->uid != $account->uid.
Default theme_username links to blocked user's accounts, despite general user's not having access to it; my guess is that may be fixed, since theme_username has changed greatly.).
#4
@hefox: That issue is being dealt with in #345541: Link to contact form in user account and e-mails leads to 403..
#5
Waiting for the cleanups to the access function in #525504: Anonymous user should not have contact form to land before this.
#6
Adding tags.
#8
#525504: Anonymous user should not have contact form has landed ...
this patch should do the trick. Please to review
#9
Can we add a small test for this to make sure regular users cannot access blocked user contact form but 'administer users' can?
#10
same patch as #8 but with two new tests:
- admins can still contact blocked users
- normal folk cannot contact blocked users
Tests are not my forte, so please give them an extra glance
#11
Not sure this is valid. I can easily think of a use case where it would be good if blocked users could still be contacted.
#12
@Dries: by non-admins?
#13
+++ modules/contact/contact.test 13 Jan 2010 02:45:38 -0000@@ -347,6 +347,20 @@ class ContactPersonalTestCase extends Dr
+ $this->contact_user = $this->drupalCreateUser();
+ $this->contact_user->status = 0;
I don't think this would actually persist? I think we would need to use user_save().
+++ modules/contact/contact.test 13 Jan 2010 02:45:38 -0000@@ -347,6 +347,20 @@ class ContactPersonalTestCase extends Dr
+ $this->drupalLogin($this->admin_user);
$this->admin_user is already logged in, so we shouldn't need to re-login. Helps saves a step for tests.
Powered by Dreditor.
#14
how's about this
#15
Looks good, tested locally, and the bot likes. As expected, admin users can still contact blocked users, so it's a good fix.
#16
Great, committed to HEAD!
#17
Automatically closed -- issue fixed for 2 weeks with no activity.