Corrupted admin user? DB-level fix needed!

[fedoras]

I was trying to find out why my specify-user, with supposedly admin/manager permissions, couldn’t switch collection for a particular museum database instance. So I created a user with a similar name, but different e-mail, in Specify7, but seems to have set things now in motion that cannot be undone. Whether related or not, my original user account can no longer access anything and I don’t know how to set the permissions right. And a lot of my admin/manager perks (User Tools) are no longer visible in Specify7.

I had already gotten a warning from my predecessor that there’s a bug in Specify 7 when creating users, that I failed to heed. So I’m quite certain I screwed something up, that may need to be fixed directly into the database itself using raw SQL statements. I have been looking directly into the database itself (not through Specify client software) and I also some of the other specify-databases we use and they show different values for my user in the relevant tables.

The rows in the table spprincipal related to my user all show “edu.ku.brc.af.auth.specify.principal.UserPrincipal” as the so-called “GroupSubClass”. In other databases, these take can take the values “edu.ku.brc.af.auth.specify.principal.AdminPrincipal” and “edu.ku.brc.af.auth.specify.principal.GroupPrincipal”.

So my questions are:

1. How do I fix the entries in database tables specifyuser , specifyuser_spprincipal and/or spprincipal in order to alleviate my woes?
2. What does userGroupScopeID stand for and does it have any bearing on this?

Thanks in advance for any pointers.

• This topic was modified 4 months, 3 weeks ago by fedoras. Reason: whoops copy paste from e-mail

[Author]

Posts