i have a site with anonymous comments (requiring name and email) enabled. now it happens a lot that people forget to login / their passwords and just post comments as anonymous users. thats not very nice for user and comments tracking. what would be nice is a way for admins (with 'administer comments' rights) to assign these comments - whose author they know - to the real user. thats currently not possible.

attached simple patch provides for this functionality. my site happens to run 4.7, so the patch is against 4.7. if considered useful, i will provide patches for 5.x, too.

Comments

ax’s picture

StatusFileSize
new1.44 KB

patch didn't apply - here is the real one.

gerhard killesreiter’s picture

Version: 4.7.x-dev » 6.x-dev
Category: bug » feature

that's IMO a feature and thea means it can only get into Druapl 6.

ax’s picture

StatusFileSize
new1.46 KB

hm - was afraid of that :(. well then, here we go. first a patch for 5.x ...

ax’s picture

StatusFileSize
new1.45 KB

... and here the one for 6.x.

Anonymous’s picture

Subscribing.

May be nice if we were able to assign the user automagicly via email address. I'll set a todo for myself for that.

ax’s picture

speaking of "may be nice": it would also be nice if this (alternatively) could be done as a mass-op on comments, ie. assign all selected comments in admin/comment to a certain user. unfortunately, my todo-list is too long already :(

dries’s picture

This functionality looks good.

What is the second chunk for? Is that intentional?

ax’s picture

StatusFileSize
new10.18 KB

that second chunk is intentional, yes. by adding the 'author' autocomplete form field for assigning a registered user, we always have that value in the request, even if we leave the field empty (which is the default, as the comment administration fieldset is collapsed by default). so we cannot check with isset() anymore.

i attach a screenshot, maybe this makes things clearer. note that the 'author' field is 'Assign to user:' - not 'Authored by:', this is 'name', as it is the name of an anonymous commenter and not a registered user.

ax’s picture

that second chunk is intentional, yes. by adding the 'author' autocomplete form field for assigning a registered user, we always have that value in the request, even if we leave the field empty (which is the default, as the comment administration fieldset is collapsed by default). so we cannot check with isset() anymore.

i attach a screenshot, maybe this makes things clearer. note that the 'author' field is 'Assign to user:' - not 'Authored by:', this is 'name', as it is the name of an anonymous commenter and not a registered user.

ax’s picture

that second chunk is intentional, yes. by adding the 'author' autocomplete form field for assigning a registered user, we always have that value in the request, even if we leave the field empty (which is the default, as the comment administration fieldset is collapsed by default). so we cannot check with isset() anymore.

i attach a screenshot, maybe this makes things clearer. note that the 'author' field is 'Assign to user:' - not 'Authored by:', this is 'name', as it is the name of an anonymous commenter and not a registered user.

ax’s picture

that second chunk is intentional, yes. by adding the 'author' autocomplete form field for assigning a registered user, we always have that value in the request, even if we leave the field empty (which is the default, as the comment administration fieldset is collapsed by default). so we cannot check with isset() anymore.

i attach a screenshot, maybe this makes things clearer. note that the 'author' field is 'Assign to user:' - not 'Authored by:', this is 'name', as it is the name of an anonymous commenter and not a registered user.

ax’s picture

StatusFileSize
new10.18 KB

sorry for double-double-posting. there were server errors, and apparently i pressed the reload button 3 times too often. any way do delete comments to issues?

dries’s picture

The UI looks a bit awkward to me. It might look better if the 'assigned to user' would be shown in a block next to the anonymous user stuff. Not quite sure.

The functionality is really useful, but I'd like to hear other people's ideas about this, and the UI in particular.

ax’s picture

StatusFileSize
new9.84 KB

like that (attached screenshot)?

yngens’s picture

subscribe

dries’s picture

ax: that looks somewhat nicer, yes! :)

ax’s picture

StatusFileSize
new22.6 KB

another ui option: put the "assign to user" (which probably won't get used much) in a collapsed fieldset. see attached screenshot 1 ...

ax’s picture

StatusFileSize
new24.54 KB

... and 2.

sutharsan’s picture

I agree that this is a desired functionality to be able to change/add the author.

However the interface confuses me. If the comment is by a anonymous the 'Authored by' field is empty. Now I have two options to enter a name, 'Authored by' and 'Assign to user'. I would rather see here only one field in which to enter the name or change an existing name.

ax’s picture

@Sutharsan:

the 'Authored by' field only is empty if you don't allow anonymous users to enter a name (admin/content/comment/settings). otherwise, the name they entered when submitting the comment appears.

regarding "now i have two options to enter a name, 'Authored by' and 'Assign to user'": thats why i made my second ui suggestion (#17 above) which by default hides the 'Assign to (registered) user'. would that be better?

ax’s picture

StatusFileSize
new23.24 KB

oops - just noticed that the last 2 screenshots have a problem with the form elements weights. of course the 'Assign to registered user' must be directly below 'Authored by'. new shot attached.

ax’s picture

StatusFileSize
new27.16 KB

to make things even more clear, clearly name 'anonymous' and 'registered' user fields and provide some explanation. next screenshot, with the 'Assign to registered user' fieldset expanded.

sutharsan’s picture

#22 is much better, thanks.

ax’s picture

StatusFileSize
new3.37 KB

new patch for UI and CVS changes

catch’s picture

Version: 6.x-dev » 7.x-dev
Status: Needs review » Needs work

No longer applies, moving this to D7 queue.

yngens’s picture

Applying patch for 5.x in #3 gives:

[root@host comment]# patch *.patch
(Stripping trailing CRs from patch.)
patching file comment_db_rewrite_sql_backport5.patch
Hunk #1 FAILED at 1483.
Hunk #2 FAILED at 1649.
2 out of 2 hunks FAILED -- saving rejects to file comment_db_rewrite_sql_backport5.patch.rej
[root@host comment]#

I see this moved to 7.x, but will it also work for 5.x some day?

elitefox’s picture

Version: 7.x-dev » 6.9

Sorry I am new to patch thing :)
How do apply this patch?
I have drupal 6.9 running on my machine and maybe planning to upgrade to 6.10 and if that happens will I need to apply the patch again?

Best Regards,
elitefox

ax’s picture

Version: 6.9 » 7.x-dev

please don't change versions just because *you* happen to run a specific one. thanks!

Anonymous’s picture

@elitefox: This is a support question. See http://drupal.org/support for where to ask or at least http://www.google.com/search?q=apply+patch+file.

bsherwood’s picture

+1 on adding this feature to 7.x.

I think the whole "assign to registered user" bit is unnecessary. When an admin edits a node we just use the "authored by" autocomplete field to change the creator. Can't we just make the "Authored by" field act the same way as the node/*/edit form?

elitefox’s picture

@ax

Sorry that was my first post, thought my drupal core version is needed to be stated =)

hope you will forgive me :(

rmjiv’s picture

Subscribing

pcs305’s picture

StatusFileSize
new3.18 KB

Here's a patch for 6.17 if anyone is interested. Not a patch from CVS.
YMMV, It works for me. I'm slowly working on 7 but hope someone will beat me to it ;)

yngens’s picture

Error on applying the last patch: Parse error: syntax error, unexpected '}', expecting ']' in /usr/drupal/drupal6/modules/comment/comment.module on line 1204

pcs305’s picture

StatusFileSize
new3.18 KB

Fixed the problem.

Thanks

yngens’s picture

Now it works correctly, thanks. The only caveat is that if you set "Anonymous posters must leave their contact information" then it still spits out name required notice and you can not assign anonymous comment to a registered user. The option in comment settings for a content type should be different than "must leave".

yngens’s picture

I hope this one will be committed to the core.

bsherwood’s picture

Version: 7.x-dev » 8.x-dev

Moving to 8.x

yngens’s picture

I believe one of these two nodes should be marked as duplicate to concentrate all the efforts to solve the issue at one place:

#936844: Cannot override comment author to or from Anonymous Posted by skyredwang on October 9, 2010 at 8:04am and has 21 comments to the moment
#129822: allow admins to assign anonymous comments to registered users Posted by ax on March 21, 2007 at 8:22am and has 38 comments to the moment

greenreaper’s picture

I got around the "must leave contact information" problem by adding the condition !$edit['author'] to the following else if:

      else if (variable_get('comment_anonymous_'. $node->type, COMMENT_ANONYMOUS_MAYNOT_CONTACT) == COMMENT_ANONYMOUS_MUST_CONTACT) {
        form_set_error('name', t('You have to leave your name.'));
      }

This might not be the right way to do it . . .

JoshOrndorff’s picture

I would love to see this functionality added to core. In the meantime, does anyone know of a module to do it?

-Josh

andypost’s picture

Version: 8.0.x-dev » 8.1.x-dev
Issue summary: View changes
Related issues: +#2227503: Apply formatters and widgets to Comment base fields

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs work » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

smustgrave’s picture

Wanted to bump this 1 more time before closing.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

smustgrave’s picture

Status: Postponed (maintainer needs more info) » Closed (outdated)

Since it's been 11 years without movement or interest. And was a feature request going to close out. Can always be closed out.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.