• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

pennersr / django-allauth / 1639
96%
main: 96%

Build:
Build:
LAST BUILD BRANCH: dependabot/github_actions/github_actions-76468cb07f
DEFAULT BRANCH: main
Ran 13 Oct 2016 08:46PM UTC
Jobs 15
Files 410
Run time 4min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

pending completion
1639

push

travis-ci

pennersr
Extended field serialization support

Hacky code, rationale:

A bit of background: the issue is caused by the fact that after the
provider handshake unsaved model instances are being assembled. So, we
have an unsaved User instance, a SocialAccount instance and perhaps a
SocialToken instance.

Now, it may be the case that after the handshake additional questions
are to be asked to the user using the social signup form. What happens
in this case is that the unsaved instances are stashed into the session,
to be picked up at a later time once the social signup form is
completed.

Making the serialization pluggable is an option, though it is quite a
hassle having to setup your own serialization for something as simple as
a TimeZoneField. Also, I am afraid people will easily forget about this
scenario, as depending on the flows the serialization route may or may
note be taken.

Adding support for more fields can be done. For example, the ImageField
is a regular Django field that can be properly handled. But, that won't
help you when you are using a 3rd party TimeZoneField.

All in all, I would really like to see a solution that "just works"...
leaning towards something like this:

- Add support for ImageField

- For fields that are not serializable, store the DB prep value:

  >>> instance._meta.get_field('timezone').get_prep_value(v)
  'UTC'

  And, use from_db_value when deserializing.

The above is likely to be sufficient to get things working out of the
box for most use cases. But, just in case there you have uncommon
models/data types, we can move the (de)serialize method into the adapter
so that if all else fails one can still override and adjust things as
needed.

7169 of 7688 relevant lines covered (93.25%)

13.91 hits per line

Jobs
ID Job ID Ran Files Coverage
1 1639.1 (DJANGO="Django<1.8") 13 Oct 2016 08:47PM UTC 0
92.91
Travis Job 1639.1
2 1639.2 (DJANGO="Django<1.9") 13 Oct 2016 08:46PM UTC 0
92.83
Travis Job 1639.2
3 1639.3 (DJANGO="Django<1.10") 13 Oct 2016 08:46PM UTC 0
92.81
Travis Job 1639.3
4 1639.4 (DJANGO="Django<1.11") 13 Oct 2016 08:46PM UTC 0
92.81
Travis Job 1639.4
5 1639.5 (DJANGO="Django<1.8") 13 Oct 2016 08:47PM UTC 0
92.79
Travis Job 1639.5
6 1639.6 (DJANGO="Django<1.9") 13 Oct 2016 08:48PM UTC 0
92.71
Travis Job 1639.6
7 1639.7 (DJANGO="Django<1.8") 13 Oct 2016 08:48PM UTC 0
92.79
Travis Job 1639.7
8 1639.8 (DJANGO="Django<1.9") 13 Oct 2016 08:48PM UTC 0
92.71
Travis Job 1639.8
9 1639.9 (DJANGO="Django<1.8") 13 Oct 2016 08:48PM UTC 0
92.79
Travis Job 1639.9
10 1639.10 (DJANGO="Django<1.9") 13 Oct 2016 08:49PM UTC 0
92.71
Travis Job 1639.10
11 1639.11 (DJANGO="Django<1.10") 13 Oct 2016 08:49PM UTC 0
92.69
Travis Job 1639.11
12 1639.12 (DJANGO="Django<1.11") 13 Oct 2016 08:49PM UTC 0
92.69
Travis Job 1639.12
13 1639.13 (DJANGO="Django<1.9") 13 Oct 2016 08:50PM UTC 0
92.71
Travis Job 1639.13
14 1639.14 (DJANGO="Django<1.10") 13 Oct 2016 08:50PM UTC 0
92.69
Travis Job 1639.14
15 1639.15 (DJANGO="Django<1.11") 13 Oct 2016 08:50PM UTC 0
92.69
Travis Job 1639.15
Source Files on build 1639
Detailed source file information is not available for this build.
  • Back to Repo
  • Travis Build #1639
  • cedad9f1 on github
  • Prev Build on master (#1638)
  • Next Build on master (#1643)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc