Opened 11 years ago
Closed 11 years ago
#20339 closed Bug (worksforme)
Admin shows all users as staff and super user
| Reported by: | Owned by: | nobody | |
|---|---|---|---|
| Component: | contrib.admin | Version: | 1.5 |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Hi everyone,
I have created a Django powered site for my company. Everything works perfectly, except in our production environment, where I have one bug in the admin that is quite annoying:
When I click a user to edit it, the "Staff" and "SuperUser" checkboxes are always checked for every user, even when they shouldn't be. The database however does record these properties properly, and they work correctly in the application. Only the admin is displaying them incorrectly in the "edit" page for a user. When looking at the user overview in the admin, the "staff" property is correctly displayed.
Because of this bug we need to be extra cautious when editing users, because we don't accidentally want to make anyone a staff user or superuser.
Steps for reproducing:
1) Open the admin site.
2) Click the "Users" model in the "auth" app.
3) Click any user that does not have staff and/or superuser permissions to open it for editing.
4) Notice that in the edit screen for a user, staff and superuser permissions are checked.
I am running:
Django 1.5.1 on Ubuntu 12.04 with SQL Server 2008R2 as my database (via pyodbc->UnixODBC->FreeTDS).
I suspect the database has something to do with it. If it is considered "non-supported" and has no
place here, please let me know. However, I don't experience any other issues with it. Both staff and
superuser permissions are correctly interpreted by my application and the rest of the admin (AFAIK).
Can anyone tell me what information is relevant for debugging this problem?
Thanks in advance for any feedback you can provide.
Kind regards,
Thomas
Unless you can reproduce the bug with an officially supported database backend, I'd suggest you report the bug against the 3-party database backend you are using. It might be related to a deficient conversion by the backend of the database boolean representation.