0

anyone else see update user in admin causing errors?

Brand new askbot install latest code within 1 week. linux centOS, postgresql 9.3, python 2.7.5.

running python manage.py runserver hostname -i:8000

I added the first user to get an admin user.
Second user by normal signup.
Then I go into /admin as first user and try to give the second user "staff" status.

but I get a database error:

update or delete on table "auth_user_groups" violates foreign key constraint "authusergroups_ptr_id_refs_id_e728db87" on table "askbot_groupmembership" DETAIL: Key (id)=(7) is still referenced from table "askbot_groupmembership".

it seems that in order to do this, one must first delete rows from askbot_groupmembership.

migrations all run, but somehow I am still getting this error 170 | askbot | 0170_auto__add_field_group_read_only

if anyone has any ideas, I'd appreciate some advice.

jeffmad's avatar
33
jeffmad
asked 2013-11-19 15:09:47 -0600
edit flag offensive 0 remove flag close merge delete

Comments

What is the error with the migration 170?

Evgeny's avatar Evgeny (2013-11-20 12:34:04 -0600) edit

sorry, I didn't express myself well. I meant to show that I have all migrations successful through 170, but I am still seeing this error wherein I cannot modify a user's status because of the foreign key constraint. I had initially suspected that some migration must have failed to make this error happen. I will take a look at the m2m_changed with pre_delete and try to make a patch. I would think that this is a common case to elevate someone to staff or superuser.

jeffmad's avatar jeffmad (2013-11-21 11:11:18 -0600) edit
Catskul's avatar Catskul (2014-05-30 23:04:53 -0600) edit
add a comment see more comments

1 Answer

2

The askbot_groupmembership table contains "membership level" and a link to a row in the auth_user_groups - which is the bridge table between the auth_user and auth_group. The auth_user_groups does not correspond to any model in the countrib.auth app, but is created for the ManyToMany User.groups field.

That issue may be addressed on handling the "m2m_changed" signal with the "pre_delete" argument, but it is hard to guarantee without trying by deleting the membership and simply editing the user record via the django admin.

Evgeny's avatar
13.2k
Evgeny
answered 2013-11-20 12:47:56 -0600
edit flag offensive 0 remove flag delete link

Comments

Catskul's avatar Catskul (2014-05-30 23:05:21 -0600) edit

@Evgeny, +1 on this error. I am unfortunately not well verse in DB realm. Thank you

eugenenarciso's avatar eugenenarciso (2014-06-24 17:28:30 -0600) edit
add a comment see more comments