Merge lp:~widelands-dev/widelands-website/auto_one_to_one_ractivating into lp:widelands-website
Status: | Merged |
---|---|
Merged at revision: | 432 |
Proposed branch: | lp:~widelands-dev/widelands-website/auto_one_to_one_ractivating |
Merge into: | lp:widelands-website |
Diff against target: |
295 lines (+64/-102) 10 files modified
mainpage/views.py (+0/-26) settings.py (+3/-2) urls.py (+2/-2) wl_utils.py (+51/-0) wlggz/fields.py (+0/-33) wlggz/migrations/0001_initial.py (+2/-3) wlggz/models.py (+1/-1) wlprofile/fields.py (+1/-32) wlprofile/migrations/0001_initial.py (+2/-2) wlprofile/models.py (+2/-1) |
To merge this branch: | bzr merge lp:~widelands-dev/widelands-website/auto_one_to_one_ractivating |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
SirVer | Approve | ||
Review via email: mp+310813@code.launchpad.net |
Description of the change
Another issue from the update to django 1.8:
Formerly to django 1.8 entrys to the database of wlprofile and wlggz has been created on demand.
For some reason i didn't checked this when working on the django 1.8 branch and thought the database entries got created during registering.
The last django errors from today told me that there is something wrong: A user who registered in year 2010 tried to access his profile the first time, and django through the error. For this user i created the wlprofile and wlggz database entries by hand over the admin site. Comparing the amount of users and wlprofiles i found that we have over 4000 users while there are only a bit more than 2000 wlprofiles :-S
This branch brings back the old behavior. I didn't know much about the code change, just get it from here:
https:/
So the code may need a review from a more experienced user.
This branch is tested here at home including normal registration over the registration app. I decided to move the relevant code to wl_utils because this code was used two times (wlprofile and wlggz). Additionally removed the code introduced by my misunderstanding.
We should get this in as soon as possible.
django-annoying released that fix over a year ago, so it should be quite safe.
We should compare with their current code though:
https:/ /github. com/skorokithak is/django- annoying/ blob/master/ annoying/ fields. py#L37
I noticed that this has an extra @atomic in it.