Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.http://groups.drupal.org/user/65822 -- user blocked.
However, seeing this new spam user within the context of the different tickets flying around about the need to synch accounts between d.o and g.d.o, I took a look to see if there was a corresponding username on d.o --
And, there was: http://drupal.org/user/642058 -- who is now blocked -- and blocking the user on d.o appeared to remove the user from the other *.d.o accounts.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | bakery-primary-link-625748-13.patch | 1.22 KB | coltrane |
| #8 | 625748_bakery_link_to_main.patch | 1.03 KB | greggles |
Comments
Comment #1
gregglesYes, if you need to block spam on a subsite then please block the user on d.o as well.
Comment #2
bonobo commentedAside from doing a search on username, is there an automated way to connect the accounts?
Comment #3
gregglesHow about we turn this into a Bakery feature to do just that :)
Comment #4
bonobo commentedSounds like a plan.
I didn't know if I had overlooked something on this, as I haven't followed a lot of the Bakery discussions.
Comment #5
bonobo commentedHow much Bakery information is exposed via views?
If this is exposed via views, then this would be pretty straightforward --
If someone gave me the rights on g.d.o (or preferably on the scratch version of g.d.o) I'd be glad to see if this could be done.
If the userid of the person's main account is exposed to views, this would be a simple task of grabbing that data, rewriting the output of the field to point to d.o user account, and only showing that view to users with admin user perms (or better yet, the permission to use the fasttoggle)
Comment #6
gregglesIt is stored in the init field, which I don't think is available via views. As I thought about this more, I don't see why it has to be based on "administer users" - it seems legitimate that anyone looking at a profile on a subsite should see a link to the profile on the main site. We will have to strip "/edit" off the end of the init string, but that should be easy.
Comment #7
gábor hojtsyAgreed, a public link to the master account should be fine on the user page.
Comment #8
gregglesComment #9
greggleshttp://drupal.org/cvs?commit=290944
Comment #11
drummUnless I'm missing another issue, I believe this is broken on 7.x. http://denver2012.drupal.org/user does show the Master profile heading, but no link. I'm guessing the syntax didn't get fully converted from 6.x.
Comment #12
coltraneYes, it's broken in 7.x-2.x right now.
Comment #13
drummhttp://denver2012.drupal.org/users/micah is an example of this not working. Their init field has https instead of http.
Comment #14
gregglesdrumm are you saying you deployed #12 and still have the problem?
Otherwise it could be #1338004: Do not store master protocol in init to better support mixed SSL domains that's causing that issue.
Comment #15
drummI think Ben deployed it. The link does work for http://denver2012.drupal.org/users/drumm.
Solving #1338004: Do not store master protocol in init to better support mixed SSL domains might actually be the way forward here.
Comment #16
coltraneCommited http://drupalcode.org/project/bakery.git/commit/e14423f
May touch this code again depending on #1338004: Do not store master protocol in init to better support mixed SSL domains