Bug #234
closedBlog admins are being reset to subscribers
Added by Boone Gorges over 14 years ago. Updated about 8 years ago.
100%
Description
See ongoing conversation in Basecamp. Related: http://redmine.gc.cuny.edu/issues/show/226
Updated by Boone Gorges over 14 years ago
Also related: http://redmine.gc.cuny.edu/issues/show/183
Updated by Zach Davis over 14 years ago
Do we know anything else about this? Are users editing their account, perhaps, and their role in relation to the blogs are being lost when the account is updated? Can we get more feedback from the users who have experienced this to help us determine how to reproduce the problem?
Updated by Boone Gorges over 14 years ago
The only person who is having the problem systematically is Scott Voth. I've checked his blog to see if there's any plugin etc that might be causing the problem, but I admit that I haven't looked closely into the issue in a while now.
My impression is that the problem is at least sometimes happening to users who have more than one blog, but is only happening with respect to one blog. That makes me think it's a blog-based problem, not a user-based one. That suggests that it's unrelated to their editing of their account, at least insofar as that information is stored in BuddyPress or WP user tables.
I'll be doing more research in the next few days and will report what I find.
Updated by Boone Gorges over 14 years ago
- Assignee changed from Boone Gorges to Ron Rennick
Switching this ticket to Ron for housekeeping reasons.
A brief update: Ron and Andrea have narrowed the problem down to either the New Blog Defaults plugin (if I understand correctly, creating a new blog can have the effect of resetting you to a subscriber on your other blogs) or the Group Blogs plugin.
Updated by Boone Gorges about 14 years ago
- Target version changed from 1.0.1 to 1.0.2
Updated by Boone Gorges about 14 years ago
- Status changed from Assigned to Resolved
Switching this ticket to Resolved and tentatively hoping that the problem has been resolved with recent cleanups to the Groupblog plugin.
Scott, since you've been our main point of contact for gathering evidence on the subject: Can I ask you to reopen this ticket if you lose privileges on your blogs again? Likewise, anyone else should feel free to reopen if they experience the problem.
Updated by Boone Gorges about 14 years ago
(Reposting message to make sure that added Watchers are in on the loop - sorry for duplicate)
Switching this ticket to Resolved and tentatively hoping that the problem has been resolved with recent cleanups to the Groupblog plugin.
Scott, since you've been our main point of contact for gathering evidence on the subject: Can I ask you to reopen this ticket if you lose privileges on your blogs again? Likewise, anyone else should feel free to reopen if they experience the problem.
Updated by scott voth about 14 years ago
I will Boone. I haven't experienced this problem for awhile. Hopefully it's solved.
Updated by Matt Gold about 14 years ago
Hi All,
Unfortunately, we've had a recurrence of this problem -- please see ticket 372
Should we reopen this ticket?
Updated by Ron Rennick about 14 years ago
The next time this happens can you let me have a look at the blog/user on the live site before anything is fixed?
Updated by Boone Gorges almost 14 years ago
- Status changed from Resolved to Assigned
- Target version changed from 1.0.2 to 1.2
See #467.
Ron, I think that the problem was fixed before giving you a chance to look at it. Sorry about that. I'll keep the ticket open while we lie in wait for it to pop up again.
Updated by Boone Gorges over 13 years ago
- Status changed from Assigned to Resolved
Once again, we have gone a long period of time without this problem happening again. I'm going to mark it resolved yet again. If it happens again, I'll let you (Ron) know before fixing it. Matt, please don't fix this problem right away if it happens in the future.
Updated by Matt Gold over 13 years ago
Matt, please don't fix this problem right away if it happens in the future.
You got it.
Updated by Boone Gorges over 12 years ago
- Status changed from Resolved to Assigned
- Assignee changed from Ron Rennick to Boone Gorges
- Priority name changed from High to Normal
- Target version changed from 1.2 to 1.4
See #1745.
I'm reopening this ticket. My plan is to write a small script that will be called whenever a user's blog role is changed and record who the logged-in user is, along with some other relevant data. Then, next time this issue comes up, we should have at least some sort of record of what's happened.
Updated by Matt Gold over 12 years ago
Sounds great (and smart). Thanks, Boone!
Updated by Sarah Morgano over 12 years ago
Hi Boone,
Sorry for the cross-posting, but it looks like you closed the other ticket.
I also do not have access to create hero slides.
Best,
Sarah
Updated by Boone Gorges over 12 years ago
- Status changed from Assigned to Hold
- Target version changed from 1.4 to Not tracked
I've written the script and added it in https://github.com/castiron/cac/commit/8ee9cf0f5123d7347a06463ec9c9387c1671470d. Next time someone loses access, let me know and I will check the logs.
Updated by Stephen Real over 8 years ago
Boone,
It looks like this one can be closed. You created a script to log some diagnostics. It's impossible to tell from this ticket if the underlying issue has recurred, but it seems like it has NOT. So, therefore...
Thanks,
Steve
Updated by Boone Gorges over 8 years ago
- Status changed from Hold to Rejected
Sounds good to me. Thanks, Steve.
Updated by Boone Gorges about 8 years ago
- Status changed from Rejected to Resolved
- Target version changed from Not tracked to 1.9.28
See #6017. I think I may have solved this. There were a couple of subtle bugs in bp-groupblog that caused problems when the "Enable member blog post" box is unchecked. In these cases, bp-groupblog was still attempting to change the user's blog role. This resulted in a couple weird issues:
- in the case where the checkbox was not checked, no default role mappings had been saved to the database. As such, `add_user_to_blog()` was being called with a blank role, which was setting users to Subscriber. Fixed in https://github.com/boonebgorges/bp-groupblog/commit/3e81e9971bdb53f196a27a5f7359de2d4832d204
- when leaving a group, bp-groupblog sets the leaving-member's blog role to Subscriber. This is a safety measure: a group with synced site membership probably doesn't want the user to have posting privileges after leaving the group. But this sync code was running even when the membership sync was disabled, and was happening even with users who didn't have an existing role on the site. Fixed in https://github.com/boonebgorges/bp-groupblog/commit/a52dcda6261006aec2526e5420ff2c68da9a7ca5
I don't have concrete evidence that this is what's caused all of the "lost access" problems over the last few years, but it fits the picture: there is likely one or more groups on the Commons that have the main site as the groupblog, and occasionally a group membership change would trigger these seemingly untraceable issues.
The update to the bp-groupblog plugin will be part of the 1.9.28 release: https://github.com/cuny-academic-commons/cac/commit/b889f5417f063ba0b9ebfe922fdc8b81b8e09d98