Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
As the subject says, allow anonymous website visitors the ability to email a member via their personal contact form.
Surely this is a common requirement, members don't want to advertise their email address on a website, but would like to be contacted by anybody?
Comment | File | Size | Author |
---|---|---|---|
#308 | 58224-user-contact-anonymous-D7.patch | 15 KB | Dave Reid |
#302 | 58224.031.patch | 12.28 KB | karschsp |
#301 | 58224.030.patch | 12.5 KB | Owen Barton |
#299 | 58224.029.patch | 13.78 KB | karschsp |
#297 | 58224.028.patch | 13.54 KB | karschsp |
Comments
Comment #1
Zen CreditAttribution: Zen commentedhttp://drupal.org/node/61600
Comment #2
budda@Zen: Completely different problem in that link. And some people have commented in that thread about you sending them there only to find no solution :)
Comment #3
pwolanin CreditAttribution: pwolanin commentedI agree this could be useful, and I think the only anwer I've found in looking into it so far is "this functionalty is not supported in 4.7".
Comment #4
matt@antinomia CreditAttribution: matt@antinomia commentedThis patch allows anonymous users to send members email via the personal contact form. It is highly advised that if you use this patch you use the captcha.module alongside to prevent spam bots from using the form.
Comment #5
Dries CreditAttribution: Dries commentedThanks!
I'm OK with the functionality (as long it can be disabled with a permission).
Patches should be against CVS HEAD. Coding style needs work (no tabs, placement of brackets -- see handbook for details).
Comment #6
killes@www.drop.org CreditAttribution: killes@www.drop.org commentednew feature
Comment #7
David Lesieur CreditAttribution: David Lesieur commentedThe original patch applied to 4.7, but the 'from' e-mail validation was not working (or no longer working), so I fixed it. I also added a field for anonymous visitors to enter their full name, and made sure the e-mail message includes it.
This new patch still targets 4.7 because I needed it on 4.7... Next step will be to port it to HEAD. ;-)
Comment #8
matt@antinomia CreditAttribution: matt@antinomia commentedUpdated for HEAD, although missing the deadline of the 1st. Also squashed a small bug in HEAD that didn't display the Recipient's name on the contact form because the $account variable hadn't been loaded.
Comment #9
matt@antinomia CreditAttribution: matt@antinomia commentedincluding attachment this time
Comment #10
pwolanin CreditAttribution: pwolanin commentedThe diff seems to be made in the wrong order. Otherwise, a quick review of the code looks OK, but I haven't actually tested it.
Comment #11
matt@antinomia CreditAttribution: matt@antinomia commented:blush:
Comment #12
matt@antinomia CreditAttribution: matt@antinomia commentedI've further updated this patch to disable the 'Send yourself a copy' option for anonymous users so evil spammers can't use it (per the discussion at http://drupal.org/node/69202).
Comment #13
lreid CreditAttribution: lreid commentedI could really use this feature, and as far as I can see it hasn't been integrated into contact.module,v 1.51.2.1 2006/10/18 and this patch doesn't apply to the more-recent version of contact.module. Am I missing something?
Comment #14
David Lesieur CreditAttribution: David Lesieur commentedSince this is a new feature, it won't make it into 4.7.x or 5.x.
Comment #15
lreid CreditAttribution: lreid commentedOkay, so I'm a philosopher, not a programmer. But I looked at this and that and reasoned it through and I've made it possible on the download of contact.module I had installed. See at www.norcal-nornevadafeldenkrais.org/user/1/contact for example. I'm trying to follow the instructions for making a patch file to put up, but all my lovely mac gave me was a patch file that said the whole previous module was removed and the whole new module was put in. Maybe I'm the only one who wants this anyway, but in case anyone else does, can anyone help create a patch file from my contact.module?
I think I sacrificed access controls on site-wide contact forms for access controls on user contact forms, though I'd like both.
Comment #16
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedphilosophy or not: new features are not added to stable releases.
Comment #17
lreid CreditAttribution: lreid commentedOops. I didn't mean to be posting this as a feature request. Apologies.
Comment #18
RobRoy CreditAttribution: RobRoy commentedHmmm...this is a feature request though so it should go under 6.x-dev.
Comment #19
dalinHere is a patch for anyone looking to implement this on a 4.7 installation.
Comment #20
bradlis7 CreditAttribution: bradlis7 commentedI would personally prefer if the contact form was enabled for anonymous users by role. It might be a pain in the rear to implement, but it would work in a lot of situations.
Comment #21
bradlis7 CreditAttribution: bradlis7 commentedJust to clarify in my last comment, I'm saying they can only send it to users who have a certain role (say, "employee", or "manager", etc).
Setting critical for further attention.
Comment #22
dalinThis is not a critical issue, please don't mark it as such "for further attention".
Comment #23
romandr CreditAttribution: romandr commentedIs ther a patch for dupal 5.1 to allow anonymous user to contact authenticated user via personal contact form?
Thanks in advance,
Roman
Comment #24
agentrickardPlease don't change version numbers. New features (and this is a feature, not a bug) go against HEAD.
Comment #25
mrtoner CreditAttribution: mrtoner commentedAs with #4, this patch allows anonymous users to send members e-mail via the personal contact form. It is highly advised that if you use this patch you use the captcha.module alongside to prevent spam bots from using the form.
The patch borrows heavily from the contact_mail_user () functions. It disallows sending of copies to anonymous users, adds personal contact form validation, and updates the watchdog log.
This patch is specifically for 5.1.
Comment #26
David Lesieur CreditAttribution: David Lesieur commentedIt's nice to have a patch against 5.x. However, right now new features only go against 6.x.
Comment #27
agentrickardThe patch in #25 should get a new issue and a link from here.
Comment #28
matt@antinomia CreditAttribution: matt@antinomia commentedAttached is a patch against HEAD for this feature based on mrtoner's #25. I also included the permission from my original patch (#3), renamed from 'send user contact' to 'access personal contact form'. If we don't include this permission, it's left open to all anonymous users by default. That would not be good.
Comment #29
andrewfn CreditAttribution: andrewfn commentedPlease could this patch get committed before the code freeze. It is so useful!
Comment #30
mfer CreditAttribution: mfer commentedsubscribing. Will test out later this week. This feature would be very useful for the sites I work build.
Comment #31
TBarregren CreditAttribution: TBarregren commentedPatch for Drupal 5.x.
I needed this functionality already on Drupal 5.x, so I have backported the patch provided in #25.
Comment #32
TBarregren CreditAttribution: TBarregren commentedJust for the record, it was the patch in #28 I backported.
Comment #33
David Lesieur CreditAttribution: David Lesieur commentedRe-rolled patch for HEAD, based on #28. Changes from matt's patch are:
Comment #34
mfer CreditAttribution: mfer commentedpatch didn't work for me. Not sure if it's the patch or this bug (http://drupal.org/node/147835).
Comment #35
David Lesieur CreditAttribution: David Lesieur commentedCould you be a little bit more specific about what didn't work? Thanks.
Comment #36
mfer CreditAttribution: mfer commentedoops. Yeah. There was no contact tab. Not for anonymous or logged in users and it didn't matter how I set the permissions.
Comment #37
David Lesieur CreditAttribution: David Lesieur commentedAnd without the patch, did you manage to get the tab for logged-in users?
Also, make sure that each user has enabled his personal contact form in his account settings.
Comment #38
mfer CreditAttribution: mfer commentedI'll test it again tonight. I tried this morning on a fresh copy of HEAD but HEAD wasn't working. This time I'll give it more than a once over.
Comment #39
mfer CreditAttribution: mfer commentedpatch works as advertised. I resolved my other issues.
Is there a reason that anonymous users don't have a 'send yourself a copy' check box at the bottom of the form but registered users do?
Comment #40
pwolanin CreditAttribution: pwolanin commentedAnonymous users can use a 'send me a copy' checkbox as a way to spam an arbitrary e-mail address by putting it as the from:
Comment #41
mfer CreditAttribution: mfer commentedComment #42
mfer CreditAttribution: mfer commentedIt looks good to me. Is this RTBC?
Comment #43
David Lesieur CreditAttribution: David Lesieur commentedUmm, patch did not apply anymore because of a commit this morning. Re-rolled the patch to take that trivial change into account.
Comment #44
matt@antinomia CreditAttribution: matt@antinomia commentedI just successfully applied this against HEAD and tested it. It look good to me. Marking it as RTBC unless there are any objections.
Comment #45
Dries CreditAttribution: Dries commentedThis looks a little dangerous:
We're inserting the name 'as is' in the e-mail. People could easily add Javascript behind their name, and it might be executed on the watchdog page. (Maybe I overlook something but it looks dangerous so please double check.)
Making the token optional might also be a bit of security concern -- it woud become a lot easier to use Drupal to send e-mails with automated scripts:
I'd like to see us think more about the security implications of the current code.
This patch makes it rather easy to spam people AND might have XSS issues.
Comment #46
matt@antinomia CreditAttribution: matt@antinomia commentedThanks for the security review, Dries. Rerolled as follows:
- !name replacement converted to @name to filter user input
- !name_url replacement renamed and converted to @mail to filter user input and properly describe its use
- added a form token based on the recipients name/email address (although not sure if this is satisfactory)
Question: Do I need to use @mail (as opposed to !mail) if it's being passed through valid_email_address() (i.e. is it redundant?)
Regarding the fact that this patch makes it easier to spam, how can we make it crystal clear that it would be a bad idea to allow anonymous users to 'access personal contact forms' without enabling some sort of captcha system?
Comment #47
David Lesieur CreditAttribution: David Lesieur commentedFurthermore, would it be a good idea to enhance the user setting with more options? Such as: a) Personal contact form for registered users. b) Personal contact form for registered and anonymous users. Of course, this does not replace spam control stategies.
@matt: The general rule is to use ! only when really necessary (and where the data is checked by other means), and to use @ or % in all other cases. It's better to have a few redundant checks than risk missing some. Btw, there are some !name left in the last patch, and there are other cases where @ could be used instead of !. Also, the token for anonymous users is missing in contact_mail_page().
Comment #48
drewish CreditAttribution: drewish commentedsubscribing
Comment #49
mfer CreditAttribution: mfer commentedI agree with David Lesieur on the personal contact settings. It's an angle I had not thought of before. Each user can decide if their contact form is open to anonymous users or just registered users.
I'd roll the patch but am not in a position, for a couple days, to do that.
Comment #50
matt@antinomia CreditAttribution: matt@antinomia commentedRerolled against HEAD:
- accounts for changes in Form API (#146667)
- using @name (instead of !name) in contact_mail_page_submit()
Regarding the token in contact_mail_page(), that was an error in the patch. Does it matter what we use as a token for anonymous users? At the moment, the token is only generated for authenicated users:
$form['#token'] = $user->name . $user->mail;
What's a good UI for allowing the user to select a preference? Checkboxes or radios?
[X] Anonymous users can contact me via my personal contact form
[ ] Authenticated users can contact me via my personal contact form
O Nobody can contact me via my personal contact form
O Anonymous users can contact me via my personal contact form
@ Registered users can contact me via my personal contact form
Comment #51
matt@antinomia CreditAttribution: matt@antinomia commented(that last radio option should be 'Authenicated and Anonymous users...')
Comment #52
andrewfn CreditAttribution: andrewfn commentedRadio buttons are a better match to the question because there are only three valid possibilities. (Allowing anonymous but not authenticated is an absurd combination).
Comment #53
flk CreditAttribution: flk commentedsubscribing
Comment #54
matt@antinomia CreditAttribution: matt@antinomia commentedRerolled fixing another FormAPI issue. Also added radio buttons for:
... and the logic to go with in _contact_user_tab_access(). If somebody wants to review my logic that would be excellent. I think it's a relatively clean fix.
One problem I noticed is that contact_user_page() is no longer passing the appropriate $recipient information when it loads the contact_mail_user() form.
Comment #55
matt@antinomia CreditAttribution: matt@antinomia commentedIn regards to the $recipient argument being passed, a new issue has been opened, as it appears it's a general bug in HEAD unrelated to this patch.
Comment #56
matt@antinomia CreditAttribution: matt@antinomia commentedIt also means this does not necessarily require any more work and is ready for review.
Comment #57
mfer CreditAttribution: mfer commentedcouldn't apply it to head anymore.
Comment #58
Christefano-oldaccount CreditAttribution: Christefano-oldaccount commentedsubscribing
Thanks for the patch, Matt.
Comment #59
matt@antinomia CreditAttribution: matt@antinomia commentedmfer, I just applied the patch (#54) cleanly to HEAD. contact.module hasn't changed since June 4, so the patch should still be good. Anybody else having the issue?
Comment #60
David Lesieur CreditAttribution: David Lesieur commentedIt applies to the latest HEAD here too. I will try to test it again. :-)
Comment #61
pwolanin CreditAttribution: pwolanin commentedapplies cleanly for me too. However - it fails testing. The module was not fully updated for this FormsAPI patch: http://drupal.org/node/146667
new patch attached - also a minor change so the checkbox uses #access rather than an if{} block.
seems close to ready
Comment #62
David Lesieur CreditAttribution: David Lesieur commentedFixed a typo in the user contact settings. Also filtered some t() arguments a bit more — more for consistency than usefulness, though, because those strings are only sent by e-mail and never rendered on the site (not even in the watchdog, unless I'm missing some magic).
The code basically works, but I have more questions...
Comment #63
mfer CreditAttribution: mfer commented@David Lesieur - my though on your 2 points is that there should be an access control for allowing anonymous users to use contact forms. And, when it's off the personal pages don't have that as an option nor does it work for cases where it was previously set.
The default option should be for anonymous users to not have the access. This leaves security tighter and sites that upgrade will see no change. Admins will need to go in and turn it on for the cases they want it.
A warning message about spam to administrators might be nice to have at some location. So that at least at some point they have to read a warning about spam concerns.
This is just my 2 cents.
Comment #64
mfer CreditAttribution: mfer commentedAnd it works as advertised. My previous issues were a bad setup on my end.
Comment #65
David Lesieur CreditAttribution: David Lesieur commentedRe-rolled for latest HEAD. Did not implement other changes yet. More ideas, anyone? :-)
Comment #66
matt@antinomia CreditAttribution: matt@antinomia commentedRegarding security, we can set a message when the contact.module is enabled. Too bad there's no place for a #description in the contact_perm() array. Is there any way to set a message when the 'enable personal contact forms' is enabled for anonymous users?
Regarding usability, +1 on hiding the user options when the permission is not available, which seems like a no-brainer.
Comment #67
mfer CreditAttribution: mfer commentedCan actions.module detect a form state change? If so, that could be a way to throw a message.
Comment #68
matt@antinomia CreditAttribution: matt@antinomia commented@mfer, that would be ideal but I don't think so. :(
We can do the super-obvious:
Returning to the idea of hiding the contact options on the user page, do we need to revert to checkboxes then? I'm not sure radio buttons will cut it:
1) Administrator enables 'access personal contact forms' for anonymous and authenticated users.
2) User selects 'Authenticated and anonymous users can contact me via my personal contact form' on their user settings page (value == 2).
3) Administrator decides to disable personal contact forms for anonymous users, but continue to allow authenticated users access.
4) Value of $user['contact'] is still set to 2, but it's not a valid selection anymore.
Comment #69
David Lesieur CreditAttribution: David Lesieur commented+1 for the message upon module activation. Would be nicer if we could point to a page on drupal.org, but I don't know of any Drupal handbook page about dealing with spam (except for some module-specific pages).
About radio buttons vs. checkboxes, I'm afraid we'll have the same problem with both interfaces (a user might have checked a box that is later hidden because administrators have changed the permissions). I'd keep the radio buttons: sure, in the case you have described it will look like no option has been selected, but at least the user won't be able to save his account settings without selecting one.
Comment #70
mfer CreditAttribution: mfer commentedI would stay with the radio buttons since it's what we are already using.
For the case where someone has it set to allow anonymous posts and then the admin takes that away we could use a little logic to handle the case where '2' is no longer a valid option.
What I'm not sure of is a precedent on how to do this. Does one exist?
Comment #71
pwolanin CreditAttribution: pwolanin commentedradios may be better. to avoid the problem you describe, you can use bitwise flags (as done in menus and other places).
For example:
Comment #72
matt@antinomia CreditAttribution: matt@antinomia commentedRerolled as follows:
- Hide the entire personal contact form settings on the user page if the 'access personal contact forms' permission is disabled for all roles. (This involved the creation of _contact_user_access(). Any other options would be welcome)
- Add a contact_enable that warns users about the dangers of spam.
- Uses pwolanin's bitwise flags solution
A situation can now arise where the site administrator allows authenticated users but not anonymous users to access personal contact forms. In this case, the option 'Authenticated and anonymous users can contact me via my personal contact form' will still be available to them. (Conversely, a similar problem would exist if the site administrator, for whatever reason, allowed anonymous users but not authenticated users to access personal contact forms.)
One can imagine fixing this situation by checking whether or not these options should be available before displaying them. However, that could lead to a case where the administrator allows neither authenticated users or anonymous users to access their personal contact forms, but does allow a third role (i.e. 'staff').
Any thoughts?
Comment #73
mfer CreditAttribution: mfer commentedthe form on the user account settings should be smart enough to know what options are available. if there is going to be a case where you can have anonymous users contacting but not authenticated users maybe we should switch to check boxes. Then, only display the check boxes for the available options and change the anonymous and authenticated option to just anonymous. That would leave it with 2 options:
- Authenticated users can contact me via my personal contact form.
- Anonymous users can contact me via my personal contact form.
If one of these check boxes is missing the language still makes sense.
Then, it's just a matter of checking if a permission exists to display each line and if it's checked.
Make sense? Sound ok?
Comment #74
matt@antinomia CreditAttribution: matt@antinomia commentedAgreed about making the form smarter. I think we can get around the anonymous-only situation by referencing "users with appropriate permissions" instead of "authenicated users".
Rerolled against HEAD.
Comment #75
pwolanin CreditAttribution: pwolanin commentedI don't really like this change:
why not:
Comment #76
pwolanin CreditAttribution: pwolanin commentedthis patch had some other problems too, in terms of the menu permission check, and the overly complicated way the options are built. I don't think it's important to know whether any user role *currently* has access to the permission - you can just always show that radio. An you can pass an account as an argument to user_access to check access for anon users.
New patch attached, but only modestly tested.
Comment #77
matt@antinomia CreditAttribution: matt@antinomia commentedThanks for the review/changes pwolanin, the patch is much simpler now.
The reason I was checking whether any user has the 'access personal contact forms' permission is so we can know whether or not to even show the personal contact form settings in the user's profile. At the moment, if there's no role with access to the permission, the options still appear on the user edit page. This could be confusing as David pointed out (#62).
Comment #78
pwolanin CreditAttribution: pwolanin commentedWell, I don't think this is going to lead to serious confusion, since it says 'users with appropriate permissions'.
However, thinking about this, I'm not sure the default value for the radios are going to be right if the user has allowed both AUTH and ANON access, but then the permission is revoke for anon users. Is this worth worrying about?
this currrent code looks a bit wrong in any case:
Comment #79
pwolanin CreditAttribution: pwolanin commentedComment #82
ellanylea CreditAttribution: ellanylea commentedsubscribing
Comment #83
deviantintegral CreditAttribution: deviantintegral commentedThe patch at #81 has a typo in the menu access. It is missing the 'access' key for the array.
I've attached a fixed version of the patch. Thanks for making it - I can't wait for this feature to hit core so I don't have to maintain this separately :)
Comment #90
tizzo CreditAttribution: tizzo commentedDoes anyone know whether this patch works on version 5.5?
I would guess it does not because the release notes make no mention of the contact module.
Comment #91
Bill Shaw CreditAttribution: Bill Shaw commentedwhat is it that I am to do with the patch code in order to get it to work?
I am new to this, and have have no idea where to put the code.
Thank you.
Comment #92
StevenPatzFeatures go in the latest dev.
See http://drupal.org/patch/apply on how to apply a patch.
Comment #93
rjleigh CreditAttribution: rjleigh commentedThe patch at #89 will work for 5.5 - the contact.module file has not changed at all.
To apply it in most linux distros, copy the patch file into the contact directory and type:
for more info see http://drupal.org/patch/apply
-Roger
Comment #94
dixieau CreditAttribution: dixieau commentedpatch #89 worked successfully on both 5.6 and 5.7, although on 5.7 I had to disable and enable contact and contact link twice before it worked. Quirky, but it worked.
Question, I'm a novice with patches, after you have applied a patch is it necessary to run update.php?
Thanks
Comment #95
tizzo CreditAttribution: tizzo commentedFor this patch you should not have to run update as it does not make any changes to the database. I did not run update.php and everything is working perfectly for me.
Comment #96
ggamba CreditAttribution: ggamba commentedHello,
I have read all this thread a couple of times, but I'm still quite confused:
1) can someone of these patches be used with version 6.0?
2) I have also read http://drupal.org/node/189785 , that is now marked as closed, but wasn't able to understand if and when this functionality will be included in next 6.x versions.
Thanks for any answer and all the best
Gabriele
Comment #97
coltrane@ggamba, the patch closest to Drupal 6 was probably in reply #76 but while not applying to HEAD anymore it also doesn't apply to Drupal 6.0. If the patch in #76 was re-rolled to HEAD it might not be too far off to backport it to D6, but I haven't looked at the code enough to say for sure.
As for http://drupal.org/node/189785 I think it was a Drupal 6 bug only and while related it did not have to do with whether or not anonymous users can use authenticated user's personal contact forms.
To answer some of the concerns about security, and to add even more discussion to this issue, what about if this feature was a contrib module? That way we don't expose a core feature to possible abuse and leave the new module contrib page and/or dependencies can mention anti-spam tools.
Comment #98
ggamba CreditAttribution: ggamba commentedHi coltrane,
thank you for your reply! I think that a contrib module would be the best possible solution! In fact, I disliked the idea to use a patch, but accepted it as seemed no alternatives were available. A contrib module would solve any problem and, for what I have seen searching the forums, would be appreciated by lot of people!
Thanks again and best
Gabriele
Comment #99
andrewfn CreditAttribution: andrewfn commented@ggamba I have to respectfully disagree!
This is a bug because contact pages in core do not work in the way most people expect them to. I set up several business sites, creating contact pages for all the people who needed to be contacted, and was shocked to find that guests on the site could not view them. I'm sure many other people have made the same wrong assumption.
Bugs should not be fixed by contrib modules!
Andrew
Comment #100
ggamba CreditAttribution: ggamba commented@andrewfn
I too have made the same wrong assumption in the beginning, but obviously this feature can't go in the core without some way to prevent spam, like Captcha module... anyway, I'm not a programmer but I don't think that the statement "thing not working like people expect = bug" is true, provided that the current behavior is documented in clear way.
All the best
Gabriele
Comment #101
tizzo CreditAttribution: tizzo commentedI have to say I agree with andrewfn. Drupal already allows anonymous contact forms, just not anonymous contact for users. This is not a security problem and not a spam problem so long as a captcha is used (this patch works with captcha). I think this should really be added to core. Many of my clients want this feature and it sounds like I am not alone.
Contact module has everything in place with this patch that we need. It would be redundant to move it into a contrib module that duplicates 95% of the functionality of core contact rather than simply allowing drupal contact forms to work the way that one would expect.
I may need to update this module for a client sometime in the next week or so, if/when that happens I will post a patch here.
Comment #102
rjleigh CreditAttribution: rjleigh commentedI also think the current form is a design flaw, if not a bug.
From the spam/security perspective, it can be implemented as a choice for the admin, with the default for allowing anonymous contact off, and a message about the possibility for spamn and the wisdom of combining a captcha with the form.
I've patched several sites to allow this, because a blind contact form is preferable to publishing user's emails, even if some sort of masking is used. And the central contact form gets too unwieldy if there's more than a few email destinations presented there.
Comment #103
himerus CreditAttribution: himerus commentedI have to personally say that while setting up my first major community site using Drupal, I am FURIOUS that this feature isn't in the core. Are you kidding me????? This is one of the most demanded features among many types of sites.
I am not comfortable patching, and on this project, it will have to stay in Drupal 5.x for the unforeseen future due to a large number of modules that are required for the proper functionality.
Personally, I will be working on a module over the next day or two that will implement the changes that the patches compensate for, and will require the Captcha plugin in order to ensure that spam prevention is enabled by default.
Hopefully I can put it together in a way that will allow it to be easily added to any Drupal 5.x installation.
Comment #104
mfer CreditAttribution: mfer commentedDries said he is ok with the functionality. He said that before 6 went out the door. We need to have a patch that meets drupals coding standard. So, let's roll one so we don't miss the bus on drupal 7, too.
Comment #105
chx CreditAttribution: chx commentedI have unpublished a dozen "how to apply to D5" etc offtopic things. The patch to work from is #76.
Comment #106
scottrigbyHi chx - assuming this will get unpublished, but I have no other way to ask you...
For Drupal 5.7, I tried to apply the patch in #76 (using a dry run), but chunks failed. SO I tried the patch in #83 which seemed to patch correctly. However, I uploaded to the site and doesn't seem to allow anon users to access members personal contact form.
Could I be missing a step? I'd appreciate your advice on this.
Thanks!
Scott
Comment #107
jonne.freebase CreditAttribution: jonne.freebase commentedsubscribing
Comment #108
coltrane#76 rerolled with some modifications for HEAD
Comment #109
keith.smith CreditAttribution: keith.smith commentedHere, and in possibly other places, there are some minor code style violations. Inline comments should begin with a capital letter and end with a period.
It seems like the "to access" should be "access to" here.
Ending period.
This has a typo and is a negative construction to boot.
This has a typo.
Comment #110
Rosamunda CreditAttribution: Rosamunda commentedSorry, I´m absolutely new to this discussion, and, after reading it, I´m clueless...
I´ve installed the last 5.x branch... I want anon users to contact registered users that check that option on their profiles...
Wich patch should I use??? #108??
Thanks for your help!
Rosamunda
Comment #111
thumb CreditAttribution: thumb commentedSubscribing
Comment #112
coltraneUser contact form options:
Note the change to the help text.
@Rosamunda, this patch will not work for Drupal 5. If you need this feature for Drupal 5 see the recently released contact_anon module. It may be of help.
Comment #113
wanabeanon CreditAttribution: wanabeanon commentedComment #114
Steven Jones CreditAttribution: Steven Jones commented@wanabeanon: http://drupal.org/support
Comment #115
wanabeanon CreditAttribution: wanabeanon commentedComment #116
matt@antinomia CreditAttribution: matt@antinomia commented@wanabeanon, this is not the place for that discussion. Please do not clutter this thread with unrelated support requests. Follow the link that darthsteven provided and learn how to request support through proper channels. Thank you.
Comment #117
wanabeanon CreditAttribution: wanabeanon commentedhttp://ethernet.ath.cx/clanxdrx/index.php
Comment #118
christefano CreditAttribution: christefano commented@wanabeanon: Your posts are making this issue harder to follow. Issues aren't like forum posts and some of us have subscribed to issues by email, so please don't post over and over in the issue queues unless you're willing to help move the issues towards resolution and review the patches being submitted.
Comment #119
rhimes CreditAttribution: rhimes commentedopinion - and it may be too late, but....
I think it perhaps prudent to review the brief exchange in posts #98 - 104 above.
Preface - been casually interested in this thread, which IS a feature request, NOT a bug, even if "many" (whatever weight that represents) think it's a feature that "should-a-been". I think that every once in awhile, we discover our "founding fathers" (in more contexts than Drupal) were very forward thinking, when they......
I agree with #98, ggamba's observation, that this feature may be better as a contrib mod. After all, where there's a will (or enough need/want), there's alway a way (contrib, in this case) for THOSE who want it.
Having said that though, yeah sure, I can live with it being in a core-optional module, I would just make sure that ALL of My sites had "access personal contact forms" denied for anons. I'm involved more with social networking type sites than biz sites, and I want anons to BECOME auth'd users, indeed encourage it obviously.
Besides adhering to the notion that core and core-optional modules should be the leanest and meanest that they can be (which may be a good enough case for this to be contrib), I'll opine that for as "many" sites or clients (biz or non) that think they "need" this feature, there're an equel number who don't - so let 'em choose by download/install.
AND of course, the "don't need/want" users aren't here (for the most part) expressing their inclination due to the thread title, right?
Besides my philosophical arguments though, I offer the following practical usage observations, first from an admins point of view, then the anon visitors' and finally from requirements/security consideration:
1 - don't see how this feature will remove/reduce maintenance of site-wide contact page/forms, or simile thereof. Will anons not still need a navigational method to reach user (personal) contact forms? I'm only testing/demoing D6, as not all the contrib modules I use in D5 are avail. yet, but I don't see where (yet, I'll admit) other than a reg'd users page that their 'Contact' link/tab is available (at least by default). And at that, an anon would need "access user profiles" perm - which opens up a whole other bag of worms. But, whether granted or not, I surmise that one "too unwieldy" maintenance chore is merely being traded for another (navigation method to).
2 - I'm an anon at your biz site - now it's without the "too unwieldy" contact page - I've got a "before purchase" question (not answered in pitch anywhere), let's see.. where do I go? I need "a presentation" of contact links "somewhere". Point is - you either maintain e-mail addies for site contact/forms, or you maintain page/menu URLs to user contact forms/user pages and HOPE that user keeps their addy maintained. Mister biz owner, which would you have more faith in?
3 - my experience has been (and though VERY new to Drupal, very experienced in web site dev/maintenance), no matter how "strong" the warning is..... Look, my opinion, "highly advised" is just a polite (politically correct?) way of saying "required" - when it comes to spam/captcha warning, which in all practicality, means another core-optional module.
One man's opinion, I know, but one thing that attracted me to Drupal in the first place was the lean-mean core, highly customizable - TO MY OWN NEEDS.
Thanks
Comment #120
matt@antinomia CreditAttribution: matt@antinomia commentedAfter deliberation I have to agree with rhimes that the correct solution is a contributed module, for one main reason: It seems silly to have a core feature that depends on (or at least highly recommends) a contributed module to work (CAPTCHA) to work safely. If this were a contributed module, it would simply have a dependency on the captcha.module). My worry about offering this as a core feature (so long as CAPTCHA is not part of core) is that users would not heed the CAPTCHA recommendation/warning and we'd see a lot of complaints regarding spam. So +1 for turning this into contributed module.
FWIW, this is definitely a feature request, not a bug...
Comment #121
dalin+1 to this being a contrib module for the reasons listed above.
Comment #122
coltraneThere is a contrib module already that provides a solution for anonymous users contacting registered users. It's the contact_anon module by ezra-g. It's a different solution than this patch but could work for many of you.
But as Dries said and mfer restated, this functionality is OKed for core. We need an executive decision here, review, test, and commit the patch or close this issue as 'won't fix'.
Comment #123
spaes CreditAttribution: spaes commentedThe "Anonymous" in contact_anon is the user being contacted, not the user doing the contacting. I have a staff page that lists short bios of the members of my organization. I would like users to be able to click a link on that page that allows them to contact one of these members directly using the contact form. I think this is generally the issue for site owners and it is not addressed by contact_anon (unless you have all your users create separate nodes which you then link to).
I am just a user but I would vote for the ability to decide on the spam for myself and make this patch part of the core.
Comment #124
andrewfn CreditAttribution: andrewfn commented+1 vote for this to go into core
Comment #125
rhimes CreditAttribution: rhimes commentedbeing new, not sure of the protocol here, but as it seems pertinent to the discussion and help was requested....
I'm talkin DOOB here
@spaes - will this work for you? - all links (i.e "Contact Joe Staffmember") on your "staff bio page" go to /?q=contact.
Create a contact category for each staff member (listed on page) at ?q=admin/build/contact/add - "Category" = Staff Membername, list addy in "Recipients" textarea (hint- in biz application as Joe Staffmember may be your VP Sales, Sales Mgr., or salesman, also list your "sales@yoursitedotcom" as this anon user may have a ton of money to spend while Joe VP is on vacation - personal user contact can't do) - sorry - edit auto-reply if you want (also good biz practice that personal contact can't do) - sorry again - weight/default as you like - save.
Anon goes to site contact form (already allowed), chooses "category" (recipient name), ala "generic" img attached - done
You could "spice it" a little, if you're so inclined as I've done in "other" img
Hope it helps
Comment #126
lucyp CreditAttribution: lucyp commentedCount me as another person saying "i need this" for my site.
Unless I am misunderstanding something.
rhimes i appreciate your suggestion above but it is not ideal for me
this is because in my case it would mean more decisions for the guest user, leading to them possibly giving up on sending a message. i just want to make it easy for guest users.
for example i'd like a link in my footer to "contact webmaster" that leads them -- not to the site contact form where they would have to select "webmaster" from a list -- but to a form ready-to-send to me. Can you suggest a way to do this? If we gotta send people thru the site contact form, at least we should be able to have the select list pre-selected based on what link took the guest to the site contact form. Or maybe there is some way to do this, that i just have not figured out yet.
anyway i can see that there are different use cases people are talking about there
Comment #127
rhimes CreditAttribution: rhimes commented@lucyp - not sure if "Can you suggest a way" is directed to me, but I'll respond as it seems to me another important consideration comes to bear upon the issue as I perceive it's current status - which is "need has been stipulated, but best handled in 'core' or as contrib?".
FIRST - in your example: as webmaster, you have many options, though I might caution your motive "make it easy for [anons]", as here's a list (easiest to less):
1 - mailto:(mypersonal@myISPaccount-or-myWEBMAILaccount-dot-com) - [vulnerable, don't recommend but 'easiest']
2 - mailto:(webmaster@yoursite-dot-com) - [as WM, prob have ability to create/use a "faceless" addy like this - and still easy]
3 - as in #125 - don't discount too quick, as you can set "Webmaster" (category) as default, making easier for anon. AND, whether use default or not, suggest it's easier for anons to select from drop-down than to meet a CAPTCHA test that'd be required, uhm, 'highly recommended' w/ personal contact - or would you not implement CAPTCHA?
4 - use Privatemsg (grant 'access private messages' to anons), make all contact links (wherever) ?q=privatemsg/new, AND supply username within link descrip., i.e. "contact Webmaster (use "webmaster" in "to:" field)". Suggest that user having to type/paste/address their message is still "easy" - and, as "to:" goes through validation, CAPTCHA not "required", so easier than personal contact w/ CAPTCHA.
5 - [tongue planted firmly in cheek] get this feature into core and submit the next logical "need in core" feature requests (as)......
SECONDLY - if in core, next gotta have(s) will be: perms "change own Email" for user.mod AND "change own Contact settings" for contact.mod - OR - either A - "2 emails/user in user.mod, 1 for 'account', 1 for 'contact' - or B - use separate/different email addy for contact.module than account email, or need additional contact setting "Re-route contact msgs. to alternate email" with alternate email field.
Logic being (or I'm missing driving force behind request): if "allow anons personal contact user/x", contact is controlled by user/x, not by webmaster/client site owner (as user/x sets email and Contact settings).
Comment #128
bflora CreditAttribution: bflora commentedCould someone link me to a version of the D5 comment module that's been patched using the patch in #76? I apply patches by hand usually because the setup process for doing them automatically is WAAAAY too intimidating and cumbersome for a non-dev. But the patch in this thread is way beyond my ability to apply by hand. I would be eternally grateful if someone could help me out in this regard. Thanks.
Comment #129
scottrigby@bflora - I just tried to patch D5.7 core contact.module using the patch in #76, and it definitely does not work, so don't bother.
@anyone who knows - it would be really nice if someone would help to answer the question, is there ANY patch that works for 5.7? I know there's debate about the finer points, like whether this feature should be in core or a contributed module, or exactly how this should be implemented.
But what about the people still using Drupal 5? If there's any solution that could work, even if we need to enable the CAPTCHA module, as long as there's no serious security risk, then knowing which patch to use would be really fantastic info to have!
So a friendly request to anyone who knows: If you could please just suggest how anonymous users could contact registered users – any patch or hack that can work for Drupal 5 – you'd be a hero to at least a few of us here.
Thanks in advance!
:)
Scott
Comment #130
yraber CreditAttribution: yraber commentedUse this patch : http://drupal.org/files/issues/anonymous-contact-5.x_1.patch
And then set "access personal contact forms" to anonymous users, in the access control menu.
Seems to work fine here with Drupal 5.7
Good luck.
Comment #131
scottrigbyYves – just want to say, you're officially my new hero :)
I can confirm this patch works for D 5.7
Thanks so much for going out of your way to help!
:) Scott
Comment #132
bflora CreditAttribution: bflora commentedHoly cow. You are made of AWESOME, good sir.
Comment #133
BlakJak CreditAttribution: BlakJak commentedHell yes. Thank you for the patch - i've been hunting for this functionality for nearly a year now.
Please Drupal-Gods, incorporate into future releases!
Cheers
BJ.
BTW: run the patch from the modules directory....
Also BTW: I ran it on Drupal 5.3 and it worked. For various reasons I havn't upgraded further yet - coming soon...
Comment #134
waldmeister CreditAttribution: waldmeister commentedI am using drupal 6.2 - an one hunk failed..
This was not the problem.
Somethings changed:
does NOT work - wie NEED
...seems the handling of permissions has changed.
Another change is the drupal anonymous user.
http://drupal.org/node/204411
so please change
$anon = user_load(0);
to
$anon = drupal_anonymous_user();
took me some time now ;)
Great thing! Please add! (+1 ^^)
Comment #135
christefano CreditAttribution: christefano commentedD6 won't be getting any new features.
Comment #136
topwaya CreditAttribution: topwaya commentedHas anyone got this working for Drupal 6.3? Help!
I started a site last week, now I have members (authenticated users) that have clients (anonymous users) that can't contact them via their Contact form.
I've tried to patch using the 6.2 edits, but it doesn't work. Has anyone gotten this to work with 6.3?
Thanks for any help!
Comment #137
albertoperego CreditAttribution: albertoperego commentedI need this feature too!
Actually, I've made my choice to using drupal when I've found that it was possible to use the personal contact form by anonymous users, since this is one of the key feature I need in my project...I hope you guys will add/fix it soon for 6.3.
thanks
Comment #138
Michelle#137 see #135
Michelle
Comment #139
scottrigbyre#135 – no new features in D6, but it could be patched (like D5), right? So for 6.3, the solution in #134 could possibly be made into a patch (if it works), for anyone willing to put out the effort... yes? I'd guess the people who want this would help test :)
Comment #140
MichelleScott - Sure, you can always patch your own sites. But albertoperego sounded like he was expecting it to get into the official release of 6.3. Not only is that impossible, as 6.3 is already out, but something like this is unlikely to get into any 6.x release.
Michelle
Comment #141
deviantintegral CreditAttribution: deviantintegral commentedI just realized that no one's mentioned webform as a possible solution to this for 5.x and 6.x. It can run a PHP snippet for generating options, so you could generate a list of users and stick that in a select. It's not the same as each user having their own form, but won't require any hacks to core.
--Andrew
Comment #142
jonhinkle CreditAttribution: jonhinkle commentedI have modified the the patch code in #130 to work for 6.3. It is a modification to the core contact module so that's unfortunate, but it works and it was something I needed on my site. I've only been using drupal for a couple days and haven't read how to do patch files for everyone, but if you are in need, I guess I could send you my files. I did comment each area I changed so you can easily see my code mods.
Comment #143
Michelle@jonhinkle - This is a feature request to be put into the official release of Drupal and as such needs to be against 7.x. If you want to provide a patch for people to use on 6.3, that's great, but 6.3 won't be getting new features.
Michelle
Comment #144
scottrigby@johnhinkle - A patch for 6.3 would be lovely in the meantime :)
http://drupal.org/patch
Cheers! Scott
Comment #145
jonhinkle CreditAttribution: jonhinkle commentedSure, I understand that 6.x won't be getting any new features. I wasn't requesting it as a feature for 6.x. I was just letting people know that I have ported the 5.7 changes listed above to work in 6.3. I have tested it to some degree and it seems to work nicely. I am using the CAPTCHA module to help control spam as a side note. I will read the patch page when I have a few minutes and post something here. Thanks
Comment #146
Michelle@jonhinkle - That's great and I'm sure will help a lot of people. I was just letting you know why I undid your settings change on this issue.
Michelle
Comment #147
swaroopch CreditAttribution: swaroopch commentedConverted the patch meant for Drupal 5.7 (http://drupal.org/node/58224#comment-850397) to Drupal 5.9.
I'm attaching it here for anyone else who might find it useful.
Comment #148
binford2k CreditAttribution: binford2k commentedDrupal 6.3 patch:
http://lug.wsu.edu/~ben/drupal_anonymous_contact_D6.patch
There is a slight visual bug. A spurious <> shows up after the submit button, but within the form and I haven't been able to track it down. Perhaps someone with a bit more time could do so and post the resolution.
Comment #149
romansta CreditAttribution: romansta commentedThanks, Version in #147 works for me.
Comment #150
jonhinkle CreditAttribution: jonhinkle commentedI quickly read the patch page and it looks like I'll need a specific tool that runs on *nix type machines. Unfortunately I don't have that type of machine, nor do I have the time to mess with Cygwin. I'll post a couple of patch files from created from WinMerge. They are fairly readable. It has the line numbers with an arrow pointing to what gets removed/inserted. Also, I put some comments in the code so I can quickly look at my files and know what's changed in case I need to upgrade so you can ignore those if you would like. Hopefully this helps someone.
Comment #151
deviantintegral CreditAttribution: deviantintegral commented@jonhinkle: See #143 above as to why this is for 7.x, not 6.3. When you change those fields it updates the whole issue, not just your single comment.
Also, those are the same as 'regular' patches - on *nix, patch without the -u (unified) flag. Surely WinMerge can handle unified patches, and if it can't, then you should find a tool which can :)
--Andrew
Comment #152
mfer CreditAttribution: mfer commentedSo, is anyone who wants this going to roll a patch against D7 so we can try and get this in early? Scrambling at the last minute to get a working patch didn't work to get it into D6.
Comment #153
binford2k CreditAttribution: binford2k commentedThis is a straight (and completely untested) port of #148 to D7. I don't have time to set up a D7 site to test with, so I'd appreciate if someone could verify whether this runs.
http://lug.wsu.edu/~ben/drupal_anonymous_contact_D7.patch
Comment #154
Andy Inman CreditAttribution: Andy Inman commented> patch -u <58224_drupal59.patch
patching file contact.module
patch: **** malformed patch at line 12: @@ -101,7 +103,9 @@
Don't understand :( I looked at the file and can't see anything strange about line 12.
> patch -v
patch 2.5.4
Comment #155
decafdennis CreditAttribution: decafdennis commentedI get the same error as #154 when applying the patch of #147.
Comment #156
decafdennis CreditAttribution: decafdennis commented#130 seems to work fine for 5.9 though.
Comment #157
Sutharsan CreditAttribution: Sutharsan commentedMoving all usability issues to Drupal - component usability.
Comment #158
lilou CreditAttribution: lilou commentedPatches #150 no longer applies.
Comment #159
Rosamunda CreditAttribution: Rosamunda commentedI´ve installed D6. Is #148 Patch working ok? I need it for a production site.
Yeah, I have a backup, but this is really a *must* for my site.
Thanks!
Rosamunda
Comment #160
Dave ReidHere's a re-worked patch for Drupal 7 ready to review. Everything worked as expected on my site, but needs some review.
Comment #161
Dave Reid...sigh. I always forget to change the status...
Comment #167
Dave ReidThank you automatic TestbedBod for all those notices on previous patches that don't apply to the latest patch.
Something I was thinking of, should we take advantage of the information in the anonymous user cookie that is available if a user has added a comment?
Comment #168
Dave ReidNew patch uses and sets anonymous cookie information and some other small code efficiency revisions.
Comment #169
dalinUsing cookies is not consistent with Drupal Core. Can you use a session variable instead?
Comment #170
Dave ReidWell, I was going off of the cookie used from the comment module. If I really wanted to use the same method, I'd have to make a contact.js and emulate the comment.js file.
Comment #171
Dave ReidRevision on latest patch that changes the cookie functionality to work exactly like core. My glorious gift to webchick, a NEW TEST! :D With 100% pass!
Comment #172
deviantintegral CreditAttribution: deviantintegral commentedThe core functionality seems fine, though I found two possible issues:
--Andrew
Comment #173
Dave ReidIf you have 'use personal contact form' enabled but have 'access user profiles' disabled for anonymous users, anonymous users will get an access denied trying to access a user profile or a user contact form. They will not even see the form.
Comment #174
Dave ReidI'm not sure how you got the title of the page "Home", but I just hit the hourly threshold for sending messages as an anonymous user (on my site at "user/3/contact") and I get the proper page title "username | Drupal Sitename".
Comment #175
deviantintegral CreditAttribution: deviantintegral commentedUsers can still see the form if they get a direct link, which I assume is possible with views (list of users, link to their contact form). Looks like "home" is caused by the same permission not being required.
Perhaps both "access user profiles" and "access contact form" should be required to view a user's contact form.
--Andrew
Comment #176
Dave ReidCurrently, the permission "access personal contact form" is not dependent on the "access user profiles", even for registered users. That should be a separate issue.
After discussion on #drupal, I have changed the redirect for when the personal contact form is submitted to check if the user has the "access user profiles" permission, otherwise redirect to the homepage.
Comment #177
Dave ReidFixed syntax error in contact.test. Passes 100%.
Comment #178
Dave ReidRevised patch to remove the "Send yourself a copy" form element so it can't be manipulated.
Comment #179
Dave ReidDisregard last patch...forgot some code. Reworked contact_user_page to function a lot more like contact_mail_page for consistency.
Comment #180
deviantintegral CreditAttribution: deviantintegral commentedI haven't done a line-by-line review, but the patch works as advertised, and no longer allows spammer abuse via setting copy=1. A few more reviews and I'd say this is RTBC.
--Andrew
Comment #181
Dave ReidDarnit! I ran diff without -N and it didn't catch the new contact.js file. I also noticed a regression on the personal contact test since the introduction of the "send e-mail via personal contact form" permission. I've got to work on merging my new anonymous contact test and the original contact form. YAY FOR TESTING!
Comment #182
Dave ReidAlright! Merged the new anonymous personal contact test into the existing personal contact test. All contact tests pass with 100%.
Comment #183
Rosamunda CreditAttribution: Rosamunda commentedCan this patch be applied as an independent module?
I´m a bit (is "scared" the word?) hesitant to patch a core module, but yet, don´t know how to create a new module from scratch...
Creating this patch to the core module will make very difficult to upgrade.
BTW, I´m lost by now, is this patch working with 6.x version?
Thanks!
Comment #184
Dave ReidNo this patch only applies to the development version of Drupal 7, where new features are supposed to go. There is the http://drupal.org/project/contact_anon module available for Drupal 5. If this gets committed, we can work on the possibility of backporting it.
Comment #185
binford2k CreditAttribution: binford2k commentedRosamunda:
Patch #148 works on D6. I'm running it now on a production site: http://ipem.anth.wsu.edu/contact
Comment #186
Rosamunda CreditAttribution: Rosamunda commentedThank you VERY MUCH guys!
:)
Comment #187
Owen Barton CreditAttribution: Owen Barton commentedSubscribing
Comment #188
Owen Barton CreditAttribution: Owen Barton commentedHere is the patch in #147 rerolled (for Drupal 5.11, but I don't think there was any fuzz) - the main difference is that it is created from the Drupal root directory (as patches should be!).
Comment #189
agharbeia CreditAttribution: agharbeia commented+1 for this request
Comment #190
mfer CreditAttribution: mfer commentedI didn't get a chance to review the functionality but I did get a chance to review the tests in the patch in #182. Each of the different test should be in their own test method rather in one test method that tests everything. So, instead of testPersonalContact() there should be methods like testAnonymous, testAuthenticated, etc.
Comment #191
Chad_Dupuis CreditAttribution: Chad_Dupuis commentedsubscribing
Comment #192
chx CreditAttribution: chx commentedI believe it's an extermely bad idea to litter the issue with Drupal 5 patches but I dislike the idea enough that I won't bother cleaning it up again.
Edit: I mean, I dislike the idea in the issue. It definitely lowers the bar towards not just spam but other kinds of unwanted messages. I never saw a forum where unregistered people could just throw emails to members. That diminishes the value of the community. But, if can just disable it then I do not particularly care to fight it hard. I am just saying I dislike.
Comment #193
davbusu CreditAttribution: davbusu commentedIMP: this is for DRUPAL 6.6 .. i dont know if it works on other versions
I modified contact.module and contact.pages.inc so an anonymous user can use the PERSONAL CONTACT FORM. "Your name:" and "Your e-mail address:" are displayed as required textfields. I disabled sending a copy to yourself for the anonymous user because of spam (like the site-wide contact form)... I also added another email format "user_mail_anon" so when the email is sent, the recepient will receive an email of this format:
The format is the same as the one used when a registered user uses the form, but the difference is that his/her url is ommitted since in the case of an anonymous user the url would be user/0 (pretty useless to show it).
Further more i modified a bit the format of the email sent by the site wide contact form (the sent email, the copy of the sent email, and if valid, the autoreply) so the subject of the mail would be [Sitename/Contact category] instead of [Contact category] (this is useful to identify that the email is being sent from a particular website...having the category on its own makes it more difficult to retrieve the email if u receive bulks of emails)...moreover i also change a bit the content of email to the following format:
I just kept the format which is used by the personal contact form...just to keep everything more uniform..
i tested everything apart from the auto-reply thing of the site wide content form...but it should be ok
post any problems u will have. tellah
Comment #194
davbusu CreditAttribution: davbusu commenteddont forget to run update.php of course...
Comment #195
mfer CreditAttribution: mfer commentedFeature requests go against the development version of drupal. Patches that add features will never go into released versions (i.e. Drupal 5 and 6). If you want this feature now the proper place to develop it is as a contributed module. See http://drupal.org/project/contact_anon. If that doesn't meet your needs offer up patches to it or create a module that meets your needs. You'll end up with a better environment to develop this in and test it out on production sites while keeping the issue open to add this to core which is what this issue is for. Testing needs to go beyond just the features and implementation against cores standards but into the social engineering aspects of opening up a contact form to the general public this way (see #192).
The concentration of this issue should to be on drupal 7 (see #182 above) and start working that path or this will not get into drupal core. The patch in #182 needs to be updated because head has changed in ways that affect it.
I'll even go so far as to offer to review a drupal 7 patch if this is marked CNR (though I will be a harsh reviewer since there is a lot of room to go terribly wrong with this idea). Marking this as a low priority as there is no active development on D7 and the priority to work on that isn't there.
Comment #196
Chad_Dupuis CreditAttribution: Chad_Dupuis commentedRegarding chx's comment #192
I agree with you for some sites, and within forums, but it is very important to keep in mind that not every drupal site is built to foster a community. Think of a simple brochure site with say 35 sales reps for different parts of a country. The fact that there isn't a switch to allow customers to contact these 35 sales reps without having to register on a site first hinders usability. On many sites using this setting is crucial, in fact it meets the very purpose of the site. I have some drupal sites where I hide all of the user registration options as we don't want them to register - ever - but we patch the comment module so their staff can be contacted by the public.
Comment #197
MichelleFixing the version. The priority is fine. I don't know why mfer thinks D7 isn't being worked on...?
Michelle
Comment #198
Owen Barton CreditAttribution: Owen Barton commentedRerolled patch - contact module tests pass, but I haven't examined beyond that.
I removed some of the code style fixes (this should be another patch).
Comment #200
Dave ReidPatch in #198 forgot some big sections. Missing the contact.js file, the setPermission() method in the test file. I'm re-rolling with some additional changes (changing 'administer site-wide contact form' permission to 'administer contact forms'), integrating contact.js with the site-wide contact form, coding style changes (which I consider fair game since it helps clear things up), and a revised test. Will post tomorrow.
Comment #201
Owen Barton CreditAttribution: Owen Barton commentedYeah, I did add some of those, but that patch was rolled a little hastily and missed them (it was merged fully by hand, as every line of contact module it touched had changed since the last patch!). +1 for making the main system form consistent.
I also thought that setPermission() should perhaps be a more global function - either a helper function in the core test library, or even an actual API function in user module (an API for setting role permissions....imagine that!?!).
Comment #202
Dave ReidIn response to #201, hopefully we can get #300993: User roles and permissions API committed to drupalWebTestCase.
Comment #203
greg.harvey+1!
I'll be using the module mfer refers to until this trickles down to D6, but this is cool! =)
Comment #204
kmonty+1
subscribing
Comment #205
binford2k CreditAttribution: binford2k commented@comment #195
Please note that this bug has been active since Drupal 4. A patch for HEAD was posted Sept. 4, 2006.
Comment #206
mfer CreditAttribution: mfer commented@binford2k this is not a bug. It's a feature request.
Comment #207
greg.harveyThe past is past. Now someone needs to supply a patch for D7. I'm going to try and see if I can get our guys to adopt this task here, but could someone please assure me we won't be wasting our time if we do provide a patch? Don't want to spend development time on another Sept. 4, 2006. ;-)
Thanks!
Comment #208
mfer CreditAttribution: mfer commented@greg.harvey Dries previously said he would consider it if it were done well. See his posts above. That's the best I can say.
Comment #209
greg.harvey@mfer: perhaps this should be moved to a new feature request - a clean start without the noise. It could start by defining properly what the patch needs to do, so that it can be agreed what the definition of "done well" is! Everything is here in this thread, including most of a patch, but no one seems to have written the functional requirements in a sensible fashion, which doesn't help.
I don't think this is going to be a huge task to do properly, but it would be good to organise it a bit, since it's potentially destined for core. =)
Comment #210
Dave ReidBy tomorrow I should be done with my complete D7 patch (based from patch #182) that has a thorough test suite.
Comment #211
greg.harveyAwesome!! =)
Comment #212
j0rd CreditAttribution: j0rd commented+1 for voting this into core. I wish it existed for 6.x. Are there any modules for 6.x which provide this functionality? Contact Anon is for 5.x only. http://drupal.org/project/contact_anon
Comment #213
j0rd CreditAttribution: j0rd commentedI needed this functionality for a module i've created for one of my sites. It's a spin off of this thread and contact_forms module. Some people might find it useful if you're lazy like me and just want your Anonymous Users to be able to send emails to users on your site.
I call it Contact Users module. It was originally intended to provide an extension to the normal user contact forms to allow you to pre-fill subject. It worked, but then I tested it for anonymous users and noticed the limitation =(.
So I incorporated davbusu's contact module patches to allow anonymous users to access the personal contact forms. I've copied the code required from there and included it into my module, so you don't need to patch core. Duplicate code on the other hand becomes an issue and should this module get wide spread for consumption, it would have to be kept up to date with all contact.modules updates.
Two features of the module aside from pulling in the patched code.
user/1/contact/Subject of the email
This will send an email to UID=1 with the pre-filled subject of "Subject of the email"
user/1/contact/123
This will send an email to UID=1 with the pre-filled subject of "Re: [node:nid=123]->name"
If node (nid=123) has the title of "My Node Title" the contact form will be pre-filled with "Re: My Node Title". I also check that the user who is emailing about a node has permission to view that node (un-tested though)
user/1/contact
** My module does not override this menu item, so it will use the default code in contact.module in which anonymous users can not email users. You will have to switch the priority of contact_users.module menu item (if you can do that in D6) or switch the path of the menu item to allow for this.
I'm going to clean this up in a bit and perhaps ask the author of Contact Forms module to include this with his package for D6 while we wait for D7.
Comment #214
Renee S CreditAttribution: Renee S commentedThis rocks my socks off.
However...switch the priority of contact_users.module menu item? Wha...? :)
[edited]
Comment #215
Renee S CreditAttribution: Renee S commented[removed]
Comment #216
Owen Barton CreditAttribution: Owen Barton commentedPlease post modules as contrib projects, not to the Drupal core issue queue!
http://drupal.org/node/22286
Comment #217
spiffyd CreditAttribution: spiffyd commentedsubs
Comment #218
Dave ReidComment #219
joachim CreditAttribution: joachim commented@#212: the contrib module contact_anon is not the functionality in question here: contact_anon allows users to contact the author of a node without knowing who the author is. I don't know from the project page if the sender may be anonymous or not. That module is not using the word 'Anonymous' in the way we tend to use it within Drupal. 'Anonymous' means 'not logged in'. That module should perhaps use another word to avoid confusion, like 'blind contact'.
Anyway.
+1.
This is important functionality that clients expect.
Comment #220
Dave ReidComment #221
chx CreditAttribution: chx commented#355513: Create an anonymous user API I smell this is needed first. After all, you want to leave your name and email where you can be contacted at the very least.
Comment #222
Dave Reid@chx, Yes it'd be nice, but my guess is that it might be a bit. In the meantime, this can get in and I'll be more than happy to implement the anonymous user API with comment.module at the appropriate time.
Comment #223
karschsp CreditAttribution: karschsp commentedSince I did a little work on this over at http://drupal.org/node/371621 I took the patch from @#182 and merged it with mine. There's a new permission, 'access personal contact form' as well as a new option for authenticated users to choose whether or not they want anonymous users to be able to contact them. if an anonymous user goes to the contact page, assuming the correct permissions are set, they see textfields for "From" and "Email", however i'm using variable_get('site_mail') as the from address.
thanks!
steve
Comment #224
greg.harveySounds great - I'll set this back to "needs review" then, shall I? =)
Comment #226
karschsp CreditAttribution: karschsp commentedSorry about the previous patch. re-rolled and attached. Nothing's changed except a proper newline at the end of the patch.
steve
Comment #228
karschsp CreditAttribution: karschsp commentedFour days of learning simpletest later, I have a new patch that should pass all the tests but I'll keeping it CNW until I can clean it up a little more.
steve
Comment #229
KarenS CreditAttribution: KarenS commentedI just marked #386572: Giving permission to contact any user and #138574: Add "create personal contact form" permission as duplicates. There's obviously a lot of interest in getting more control over contact page permissions.
Comment #230
karschsp CreditAttribution: karschsp commentedHere's an updated patch for this issue.
Comment #231
keith.smith CreditAttribution: keith.smith commentedThere's a number of issues with #230:
- code style
- comment formatting
- debugging code still in patch
Comment #232
karschsp CreditAttribution: karschsp commentedSorry about that. Here's a quick re-roll.
Comment #234
karschsp CreditAttribution: karschsp commentedHere's an updated patch that should hopefully make it past the testing bot! :)
Comment #235
tstoecklerWorks as intended, though the help text on user/x/edit could be improved IMO.
Currently it reads:
1. The titles should be improved. Right now it seems as though the second part is a sub-option of the first part, which it isn't. You can allow anonymous users to contact you, while disallowing registered users to do so.
2. The help text currently only differs in "other users"/"anonymous users". I like that the text is nearly identical because that makes it clear that the functionality is basically the same, but the first help text should read "registered users" to make the distinction to anonymous clearer.
Leaving NEEDS REVIEW to encourage some further reviewing.
Comment #236
karschsp CreditAttribution: karschsp commentedHmmm....How about like the following:
Let me know what you think and I'll re-roll.
Thanks!
Comment #237
karschsp CreditAttribution: karschsp commentedHmmm....How about like the following:
Let me know what you think and I'll re-roll.
Thanks!
Comment #238
scottrigbyHow about keeping the repeating text as help text at the top of the fieldset, rather than repeating it? Like:
Comment #239
karschsp CreditAttribution: karschsp commentedHere's a patch that incorporates the latest help text suggestions.
Thanks!
Comment #240
malc_b CreditAttribution: malc_b commentedAnother solution for D6 (and probably D7).
Add email field to cck. On the display fields tab is the option to display the email as a link or as an email form. Select form and job done. Give the user access to edit this page and it is a personal contact form. Make it admin only and it is a site wide contact form.
Comment #241
tstoecklerIMO #240 is more of a workaround for the current situation (without the genuine existance of this feature). Using the permissions system like the patch does is a great approach. Oh, and: There's no CCK UI in Core and e-mail field in core is a different topic.
Comment #242
greg.harvey@tstoeckler: I agree entirely. This is a CORE issue and since CCK is not core then a CCK solution is not a solution.
@malc_b: Thanks for sharing a workaround though. =)
Comment #243
Dries CreditAttribution: Dries commentedStill plenty of code style issues with this patch. For example, documentation sentences start with a capital letter and end with a point/dot.
Comment #244
karschsp CreditAttribution: karschsp commentedRe-read the coding standards and tried to clean things up. Please let me know if I missed anything.
Comment #245
chx CreditAttribution: chx commentedI am OK with the patch despite previous concerns. The permission makes it opt in and the use case (contacting sales reps) is a valid use case.
Comment #246
pp CreditAttribution: pp commentedIt works.
I think so It has a usability mistake:
When i edit my user profile I see the "Personal contact form settings". It not depend on anonymous or registered user role has "Access personal contact form". If they not has this permission the user/uid/contact is "Permission denied". If I am a simple site user I see this options and see my contact form link. I check every role permissions and send an email my contact form link. The link is not correct (permission denied) but when I see it look like correct (perhaps user access own contact form.) It is incoherent. User will not know what is it?
I suggest not show this options when role not have permissions.
pp
Comment #247
caktux CreditAttribution: caktux commentedComment #248
karschsp CreditAttribution: karschsp commentedFirst of all, thanks for the reviews! :)
Secondly, just to clarify, you're saying that the user should NOT be able to contact himself if his role (registered user) does not have the proper permissions?
Comment #249
pp CreditAttribution: pp commentedI think that the user/#uid/edit form should contain only one checkbox: enable/disable personal contact form. But if you want the user to set the permissions per roles, then show only the roles which have "access personal contact form" permission in the form. Now you are always showing two roles (annonymous and authenticated) at the same time.
pp
Comment #250
Dave ReidThere is an existing issue about the "being able to contact yourself" here: #345541: Link to contact form in user account and e-mails leads to 403..
Comment #251
karschsp CreditAttribution: karschsp commentedHere's an updated patch that implements what @pp is proposing in #249. It passes all my local simpletests however I am getting:
on user/%/edit. When I remove the patch, I still get that notice so I'm thinking it's unrelated.
Comment #252
Dave ReidI feel like we are starting to kill kittens with this patch.
- Adding multiple personal contact form checkboxes? That's going to need a large usability review and should be a followup patch.
- The phpdoc block in contact.install? There's an existing patch for documentation improvements: #440830: Coder and documentation review.
- Allowing users to see their own contact forms, there is an existing issue at #345541: Link to contact form in user account and e-mails leads to 403..
- Re-using the comment.module cookie to automatically fill in user name and e-mail? Split out into #440876: Reuse comment.module's anonymous cookie information.
- 403s on redirection after the contact form is submitted (aka user does not have access to user profiles): #299216: Access failure after using personal contact form
I don't want to have such an often-requested feature get derailed and not make it in. Let's please take a look at the minimum that needs to be added and help slim down this patch. It will be easier for Dries/webchick/anyone to review and easier for making sure we have all the tests we need for this feature.
Comment #253
karschsp CreditAttribution: karschsp commented@DaveReid, I kinda feel the same way. I guess that's what happens with an issue that's 3+ years old! :)
I'm willing to slim it down...but what should it be slimmed down to? I actually like @pp's idea to just have a single checkbox for enabling/disabling the personal contact form. Is that all it should be? And an additional permission "Access personal contact form"?
Comment #254
Dave ReidI'm +1 for the single checkbox behavior ("enable my personal contact form") like we currently have, and additional 'access personal contact form' permssion and (possibly) renaming the 'administer site-wide contact form' to 'administer contact forms'.
Comment #256
karschsp CreditAttribution: karschsp commenteda slimmed down patch. provides a new permission "access personal contact form" and a checkbox on the account page to "Enable personal contact form."
Comment #257
dmitrig01 CreditAttribution: dmitrig01 commentedneeds to be on two lines
why commented out? if it's commented out why not just remove it
Comment #258
karschsp CreditAttribution: karschsp commentedhere's a quick re-roll that takes care of the issues mentioned in #257
Comment #259
Owen Barton CreditAttribution: Owen Barton commentedI think the single checkbox is also idea from a simplicity/usability point of view. The only thing I think we might want to do is to alter the description for the checkbox depending on the admin set permissions, so that it is clear what the user is checking (i.e. just site users, or also anonymous users?).
Comment #260
karschsp CreditAttribution: karschsp commentedforgot to change to "needs review"
Comment #261
pp CreditAttribution: pp commentedI looked into the patch
your code:
I suggest:
I suggest do not change the contact_user_form() function.
Why is "global $user;" necessary in the contact_mail() function?
pp
Comment #262
Vacilando CreditAttribution: Vacilando commentedSubscribing, with hope it will be backported to D6 soon.
Comment #263
jurgenhaasSubscribing, would like to have that in D6 too.
Comment #264
borfast CreditAttribution: borfast commentedIs patch #258 for 7.x or 6.x?
This is actually a feature that I don't understand why never got implemented. It's simple enough and it's not really some new functionality.
I totally understand and agree with the "no new features in a stable release" philosophy but this is such a simple thing and at the same tim so many people request it, that I think I'd open an exception and implement it in 6.x.
But it's totally understandable if it doesn't get into 6.x - but in that case, please, please, please, put it into 7.x! :)
Raul
Comment #265
mattrweaver CreditAttribution: mattrweaver commentedHas this patch been applied to the any production releases, 5 or 6?
Comment #266
pdcarto CreditAttribution: pdcarto commentedI second the request for a D6 port. Even if it never goes into an official release, a patch sure would make a lot of people happy (though I'd be happier if it were put into an official release).
This thread has been around for over three years and consensus seems to have been reached long ago that this is a legitimate feature request - I'm guessing long before the D6 feature set was frozen. (One could argue that this is supposed to be in the D6 feature set and its failure to actually have appeared is a bug!)
Alternatively, does anyone have thoughts on what would it take to make this a separate D6 module?
Comment #267
Owen Barton CreditAttribution: Owen Barton commentedGuys, if you need this for D6, use http://drupal.org/project/contact_anon - if you want this in core for D7 then you need to help polish up the patch and review it.
Comment #268
borfast CreditAttribution: borfast commentedOwen, that module is actually for D5 :(
Besides, it only allows anonymous users to contact a node author - in my case (and I'm guessing there's a lot of people in the same situation) I want anonymous users to be able to contact any user, because 99.9% of the users I want to have contact forms for, don't have any nodes of their own.
As for polishing the patch, I asked before which version was this patch for, 6.x or 7.x, but I was completely ignored. I'm now guessing the patch is for 7.x, am I correct?
Comment #269
karschsp CreditAttribution: karschsp commentedyup, the patch is for 7.x, although it doesn't apply at the moment. i will update it this week.
thanks!
Comment #270
pamreed CreditAttribution: pamreed commentedI also would really like this feature for D6. I have been trying to follow comments. #267 suggest using contact_anon module but it does not have D6 release. Which is the correct patch for D6 and is it working/stable? or What is the suggest way to get this feature for D6?
Thanks!
Comment #271
binford2k CreditAttribution: binford2k commented@pamreed #148 isn't elegant, but it works.
Comment #272
chip CreditAttribution: chip commentedsubscribing
hoping for a version backported to D6
Comment #273
Owen Barton CreditAttribution: Owen Barton commentedThere is no suggested way to get this for D6 - the contact_anon module noted above has a rough D6 port in the issue queue, and the maintainer may well accept patches to add "contact any user" functionality. Please note the version field for this issue - there is no need to post in this issue unless you are working on or reviewing the patch for Drupal 7. Part of the reason this thread has not moved forward is that people are spending time requesting/backporting the code to old versions (I was guilty of this too!), rather than actually getting it into the version that is currently accepting patches.
Comment #274
karschsp CreditAttribution: karschsp commentedI'm keeping this set at "needs work" for now but here's a patch that should apply against HEAD. Still needs some cleanup and some more tests written.
Comment #275
josephcheekI ported #148 to Drupal 6.12 and am using it at http://joseph.cheek.com/. Details at http://joseph.cheek.com/node/8 and patch at http://joseph.cheek.com/sites/default/files/drupal_anonymous_contact_D6.....
Joseph Cheek
Comment #276
tahiticlic CreditAttribution: tahiticlic commentedWorks well! just remember to enable the functionnality in users permissions.
Comment #277
karschsp CreditAttribution: karschsp commentedHere's an updated patch that should apply against HEAD.
Comment #279
karschsp CreditAttribution: karschsp commentedThis one should make it past the testbot.
Comment #280
roderikThe links in comment #275 don't work.
There is obviously a need (or at least a want) for people to patch D6 and not use the contact_anon module. So I posted my latest patch in #328214: Drupal 6.6 Personal Contact Form for Anonymous and added option of setting Permision ' access personal contact form '.
(Don't worry, I won't unmark the issue as duplicate or anything. I just wanted a space to post the patch for interested people - and to get out of the hair of the D7 people in this thread who don't want these things here.)
Comment #282
gpk CreditAttribution: gpk commented@279: this patch looks as if it will reverse #229660: Use theme_username() in the personal contact form.
Also is setting a form token necessary/of any point for anonymous users? I notice that the site contact form has
Comment #283
KarenS CreditAttribution: KarenS commentedThere are several lines here (12 or so) that do nothing but change the variable name from $user->contact to $user->personal for no apparent reason. It makes the patch longer and it has the effect of turning off personal contact forms for every existing user, since the variable that is already set in their record is no longer being used. Every single user will then have to log into their form and re-select the option to make their contact form available. I think that part of the patch should be ripped out. There is no reason to change the variable name.
We definitely need to get some way to to restrict this into the code or it will be fairly useless for the use case that has been repeated over and over through this thread, a business that has specific staff people who need to be contacted by anonymous users. In its current state, every single user that wants to use a contact form would get the same behavior, which would hardly ever be a reasonable situation. Yes, it could be a follow-up patch, but we're getting close to code freeze and if this gets in without that it will be a real problem, so that needs to be a high priority.
Comment #284
karschsp CreditAttribution: karschsp commentedUpdated patch attached, although it's not yet passing all tests (well, it's not passing *one* test). Hopefully this fixes some of the issues identified in #283 and #282. I just wanted to post what I had for review for now (since it's time for bed now :)
Thanks for the feedback!
Comment #285
karschsp CreditAttribution: karschsp commentedHere's an updated patch.
Comment #286
webchickFree random patch review, courtesy of Dreditor! :)
Indentation seems off here.
I think this check can be replaced by if (empty($account->contact))
privacy.
The t() string should be in single quotes since we aren't doing variable interpolation.
There are two spaces between the sentence. Should be one.
Same deal here with the single quotes.
Indentation is off in this section again.
Also, given that both name and mail are user-supplied values, I'm not sure they're sufficient as a token? Might be worth getting someone from the security team to check this out.
'#type' => checkbox belongs on the next line.
Indentation.
Indentation.
These should be formatted as elsewhere in core (no 'string', description on separate, indented line)
This review is powered by Dreditor.
Comment #287
karschsp CreditAttribution: karschsp commentedwebchick, thanks for the review. Here's an updated patch that addresses most of the issues identified in #286. I'm not sure about the token issue, anyone care to weigh in?
From webchick: "Also, given that both name and mail are user-supplied values, I'm not sure they're sufficient as a token? Might be worth getting someone from the security team to check this out."
Comment #289
karschsp CreditAttribution: karschsp commentedre-rolling. hopefully can get this in before code freeze.
Comment #290
karschsp CreditAttribution: karschsp commentedforgot to change status.
Comment #291
drewish CreditAttribution: drewish commentedLooking good but still needs some work. Lets see if we can get this in before #300 ;)
I think we could simplify this a bit:
to:
In contact_personal_form_submit() the name handling seems really odd. Some stuff goes into the $user and $account objects other stuff is in $username and $from. You should either edit the global $user object or leave it totally alone. And why bother with the $values array? $form_state['values'] isn't that much longer and it makes it a lot clearer where it's coming from.
Why are you changing the $invalid_recipients value in the test?
This needs to be cleaned up:
either uncomment it or delete it.
The indenting on this is wacked:
Comment #292
karschsp CreditAttribution: karschsp commentedThanks for the review. Attached is an updated patch that addresses the issues in #291. Please let me know if I missed anything.
Comment #294
karschsp CreditAttribution: karschsp commentedThis patch addresses the recent change in the permissions path.
Comment #295
drewish CreditAttribution: drewish commentedMuch better!
Noticed a few small things in the tests this time:
Let's ditch those trailing new lines.
There's also a lot of comments like:
that need to be proper sentences and end with periods.
Comment #296
karschsp CreditAttribution: karschsp commentedHere's an updated patch that cleans up the spacing and commenting issues in contact.test.
Comment #297
karschsp CreditAttribution: karschsp commentedLast patch included some extra stuff. Here is the cleaned up patch.
Comment #299
karschsp CreditAttribution: karschsp commentedHere's the latest and greatest. It fails on PHP 5.2.9 due to #558534: Site-wide contact form tests failing on PHP 5.2.9, but should pass the bot.
Comment #301
Owen Barton CreditAttribution: Owen Barton commentedHere is a patch that should fix the tests (there was a attempt to disable personal contact form by default, even though it was already disabled). I also removed the setPermissions() function, since this duplicated the user_role_set_permissions() function.
The only code I did not follow was this:
How is this relevant to this issue (if not it should be another issue!), and why is 'invalid@site.' changed to 'invalid_recipients.'?
Other than that I reviewed the rest of the code and I think this is very, very close.
Comment #302
karschsp CreditAttribution: karschsp commentedOwen, Thanks for the review and cleanup. Yeah, I thought I took that $invalid_recipients change out of that patch. It was related to a problem I was having on PHP 5.2.9. When I run the tests locally, I'm getting 2 fails related to that line, but it should pass the testing bot. (I created a separate issue in #558534: Site-wide contact form tests failing on PHP 5.2.9 )
Anyway, here's the latest patch that sets that line back to the original, let's see if it passes.
Comment #303
Dave ReidSetting a reminder to get this reviewed and RTBC'd tonight.
Comment #305
ianchan CreditAttribution: ianchan commentedsubscribe
Comment #306
Dave ReidUsing cookie information has been split out into #440876: Reuse comment.module's anonymous cookie information.
Going to split the admin permission renaming into #597784: Rename 'administer site-wide contact form' to 'administer contact forms'.
Re-rolling the rest tomorrow.
Comment #307
Dave ReidFYI *lots* of awesome changes happening in contact.module. Will make rolling this a little bit easier.
Comment #308
Dave ReidHere's the revised patch after all the recent changes. I think this is getting close and could anyone's help to review and get committed soon!
Comment #309
Dave ReidFYI because this issue has become too long and is flooding the test-bot with re-test requests, and to help make this issue more clear to the core committers, I've made a new, clean issue for this at #601250: Allow anonymous users to use personal contact forms. Please only post in that issue if you are actually reviewing the patch and want to set it as 'reviewed & tested by community'. Don't put any subscribe comments in the new issue.
LET'S GET THIS DONE!
Comment #310
Dave ReidMarking this back to active so it won't get any patches tested by the test bot anymore.
Comment #311
Dave ReidExactly three and a half years from when this issue first started, this is now committed to Drupal core. I am officially closing this issue since #601250: Allow anonymous users to use personal contact forms was committed. Keep posted to the Contact anonymous for a Drupal 6 backport of this feature. Thanks everybody!
Comment #312
buddaI let out a small "woo" when I saw the commit finally :) Good work guys.
Talking about old issues, how about http://drupal.org/node/33122 ;-)
Comment #313
Marticus CreditAttribution: Marticus commentedDoes this affect 6.15? I can't get it to allow anonymous access to person form. I've enabled anonymous permission for site-wide and enabled personal form in user profile. Still no go. Which backport is actually working? There are so many listed above.
Comment #314
roderikThis is a D7 thread. D6 discussions (which will never ever cease until a year after D8 comes out :p) are best done at #328214: Drupal 6.6 Personal Contact Form for Anonymous and added option of setting Permision ' access personal contact form '.
Comment #315
Dave ReidYes, this feature is available only for D7's contact module currently. I've changed my plan and have started a drop-in Contact replacement module that will contain backports from D7 for the D6 version and also experiment with new stuff for its D7 version.
I'm going to close comments on this issue so none of the 300 people on here get e-mailed again.
Comment #316
frutelaken CreditAttribution: frutelaken commented#302: 58224.031.patch queued for re-testing.
Comment #317
Dave ReidI will block the next person who re-opens this by clicking any retest links.