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

LAST BUILD BRANCH: dependabot/github_actions/github_actions-76468cb07f
DEFAULT BRANCH: main
Ran
Files 407
Run time 27s
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
coverage: 92.71% (+0.02%) from 92.692%
DJANGO="Django<1.9"

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.

7122 of 7682 relevant lines covered (92.71%)

0.93 hits per line

Source Files on job 1639.10 (DJANGO="Django<1.9")