-
-
Notifications
You must be signed in to change notification settings - Fork 996
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"User has no profile" error after migration #4746
Comments
Not sure whether it makes any difference, but the database source was a dump of the database of a production server, where the database name is |
That's strange. All newly created users since 2.6 should have profile (see 7919a61). The previously imported ones were handled on the fly before and since the 3.4 there was migration to add profile for all existing users (see 04b9fa8). So there should be no user without profile unless it was manually created in the database. This SQL should give you list of affected users to investigate further: SELECT * FROM weblate_auth_user WHERE id NOT IN (SELECT user_id FROM accounts_profile); |
This issue looks more like a support question than an issue. We strive to answer these reasonably fast, but purchasing the support subscription is not only more responsible and faster for your business but also makes Weblate stronger. In case your question is already answered, making a donation is the right way to say thank you! |
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed soon if no further action occurs. Thank you for your contributions! |
Hi @nijel , thanks for your answer. We checked and all users in the database are affected. |
So, there is no recordds in the |
I just checked "SELECT * FROM accounts_profile;" in the production weblate. There are 707 rows. In the staging, there are none. The staging database was created by pg_dump of the whole weblate database. The staging was restored by psql on the new database. To be sure that the source problem is not outside of Weblate, we can restore the database to the original state again, then run the upper mentioned query, and then run migration again and check accounts_profile again. Please note that there is a one non-standard bit in our setup. The database on the production server is called weblate. The database on the staging server is called weblate-staging. (Note that it triggered issue #4664.) |
I just repeated the problem and found the real source of the problem. It is the database duplication. For an unknown reason, some values don't fit the constraints. As a result, psql completely ignores the whole command in the dump. Actually, there are following problems:
Looking at the Weblate admin interface, all names contain full name in both entries USER and FULL NAME (and both are the same for all names). But only this name overflows, and it overflows only in one table.
Now I am trying |
I just checked all these constraint violations one by one and it seems that there is no programming bug. All size limits there were since beginning. It seems to be a side effect of a new Django feature: database constraints https://docs.djangoproject.com/en/3.1/ref/contrib/postgres/constraints/ KONTEXT: COPY accounts_profile, line 685, column special_chars: "▸⁄⌘⌥⇧⇪↹↵−×ᵉʳᵘᵒˢ" It seems that 30 bytes is not enough for some users. KONTEXT: COPY auth_user, line 68, column first_name: "Дмитрий Горбачев" KONTEXT: COPY django_admin_log, line 335, column object_repr: "The translation contains large help strings |
Weblate doesn't use PostgreSQL specific database constraints at all (as we still support MySQL as well). Anyway the only important table out of these is How is the It might be encoding issue as well, are both your servers using UTF-8? |
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed soon if no further action occurs. Thank you for your contributions! |
@stanislav-brabec any new discoveries? I don't want it closed again :) . |
It is apparently an UTF-8 destination server issue in the destination database. Production (source):
Staging (destination):
It has nothing to do with Weblate. Weblate can do nothing. Maybe Django should refuse to use SQL_ASCII database. This is an excerpt from the dump:
|
The issue you have reported is resolved now. If you don’t feel it’s right, please follow it’s labels to get a clue and take further steps.
|
Reading PostgreSQL documentation again, it seems to be safer to explicitly enforce UTF-8. Otherwise the encoding depends on the database template encoding. |
Enforce UTF-8 in createdb. Addresses #4746 Signed-off-by: Stanislav Brabec <sbrabec@suse.com>
Thanks, committed as c09c477. |
Describe the bug
I am trying to upgrade Weblate 3.6.1 to the lastest Weblate. Following the documentation, I picked Weblate 4.1.1 as an intermediate step.
After upgrade from 3.6.1 to 4.1.1, anonymous access works as expected. But any attempt to login (for both regular user and admin) ends by error:
The web itself displays internal server error and login and it does not show logged user (there is the Log in button).
A clear and concise description of what the bug is.
There were no errors reported by
manage.py migrate
I also tried
manage.py createadmin
, but it sees the user:To Reproduce the bug
Description should look similar to this:
Steps to reproduce the behavior:
Expected behavior
No error.
Screenshots
If applicable, add screenshots to better explain your problem.
Server configuration and status
./manage.py list_versions
./manage.py check --deploy
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: