0.15.0 (2013-12-01)
*******************

Note worthy changes
-------------------

- socialaccount: Added ``is_auto_signup_allowed`` to social account
  adapter.

- facebook: Added a new setting: VERIFIED_EMAIL.

- socialaccount: a collision on email address when you sign up
  using a third party social account is now more clearly explained:
  "An account already exists with this email address.  Please sign
  in to that account first, then connect your Google account".

- account: You are now automatically logged in after confirming
  your email address during sign up.

- account: The ``/accounts/login/`` view now supports AJAX requests.

- facebook: The fbconnect.js script is now more pluggable.

- socialaccount: Markus Kaiserswerth contributed a Feedly
  provider, thanks!

- socialaccount: Dropped django-avatar support.

- openid: First, last and full name are now also queried together
  with the email address. Thanks, @andrvb.

- openid: Compatibility fix for Django 1.6 (JSON serializer).

- account: Added support for ``ACCOUNT_CONFIRM_EMAIL_ON_GET``.


Backwards incompatible changes
------------------------------

- Instead of directly rendering and returning a template, logging in
  while the account is inactive or not yet confirmed now redirects to
  two new views: ``/accounts/inactive/`` respectively
  ``/accounts/confirm-email/``.

- The ``account/verification_sent.html`` template no longer receives the
  email address in the context (``email``). Note that a message
  containing that email address is still emitted using the messages
  framework.

- The ``/accounts/confirm_email/key/`` view has been
  renamed to ``/accounts/confirm-email/`` (human friendlier). Redirects
  are in place to handle old still pending confirmations.

- Built-in support for django-avatar has been removed. Offering such
  functionality means making choices which may not be valid for
  everyone. For example, allauth was downloading the image (which can
  take some time, or even block) in the context of the login, whereas
  a better place might be some celery background job. Additionally, in
  case of an error it simply ignored this. How about retries et al?
  Also, do you want to copy the avatar once at sign up, or do you want
  to update on each login? All in all, this functionality goes way
  beyond authentication and should be addressed elsewhere, beyond
  allauth scope. The original code has been preserved here so that you
  can easily reinstate it in your own project:
  https://gist.github.com/pennersr/7571752


0.14.2 (2013-11-16)
*******************

Note worthy changes
-------------------

- Compatibility fix for logging in with Django 1.6.

- Maksim Rukomoynikov contributed a Russian translation, thanks!


Backwards incompatible changes
------------------------------

- In case you were using the internal method
  ``generate_unique_username``, note that its signature has changed. It
  now takes a list of candidates to base the username on.


0.14.1 (2013-10-28)
*******************

Note worthy changes
-------------------

- PyPi did not render the README.rst properly.


Backwards incompatible changes
------------------------------

None


0.14.0 (2013-10-28)
*******************

Note worthy changes
-------------------

- Stuart Ross contributed AngelList support, thanks!

- LinkedIn: profile fields that are to be fetched are now
  configurable (``PROFILE_FIELDS`` provider-level setting).

- Udi Oron contributed a Hebrew translation, thanks!

- Add setting ``ACCOUNT_DEFAULT_HTTP_PROTOCOL`` (HTTPS support).

- George Whewell contributed Instagram support, thanks!

- Refactored adapter methods relating to creating and populating
  ``User`` instances.

- User creation methods in the ``Default(Social)AccountAdapter`` now
  have access to the ``request``.


Backwards incompatible changes
------------------------------

- The ``socialaccount/account_inactive.html`` template has been
  moved to ``account/account_inactive.html``.

- The adapter API for creating and populating users has been
  overhauled. As a result, the ``populate_new_user`` adapter methods
  have disappeared. Please refer to the section on "Creating and
  Populating User Instances" for more information.


0.13.0 (2013-08-31)
*******************

Note worthy changes
-------------------

- Koichi Harakawa contributed a Japanese translation, thanks!

- Added ``is_open_for_signup`` to DefaultSocialAccountAdapter.

- Added VK provider support.

- Marcin Spoczynski contributed a Polish translation, thanks!

- All views are now class-based.

- ``django.contrib.messages`` is now optional.

- "jresins" contributed a simplified Chinese, thanks!


Backwards incompatible changes
------------------------------

- The password reset from key success response now redirects to a
  "done" view (``/accounts/password/reset/key/done/``). This view has
  its own ``account/password_reset_from_key_done.html`` template. In
  previous versions, the success template was intertwined with the
  ``account/password_reset_from_key.html`` template.


0.12.0 (2013-07-01)
*******************

Note worthy changes
-------------------

- Added support for re-authenticated (forced prompt) by means of a
  new ``action="reauthenticate"`` parameter to the ``{%
  provider_login_url %}``

- Roberto Novaes contributed a Brazilian Portuguese translation,
  thanks!

- Daniel Eriksson contributed a Swedish translation, thanks!

- You can now logout from both allauth and Facebook via a
  Javascript helper: ``window.allauth.facebook.logout()``.

- Connecting a social account is now a flow that needs to be
  explicitly triggered, by means of a ``process="connect"`` parameter
  that can be passed along to the ``{% provider_login_url %}``, or a
  ``process=connect`` GET parameter.

- Tomas Marcik contributed a Czech translation, thanks!


Backwards incompatible changes
------------------------------

- The ``{% provider_login_url %}`` tag now takes an optional process
  parameter that indicates how to process the social login. As a
  result, if you include the template
  ``socialaccount/snippets/provider_list.html`` from your own overridden
  ``socialaccount/connections.html`` template, you now need to pass
  along the process parameter as follows:
  ``{% include "socialaccount/snippets/provider_list.html" with process="connect" %}``.

- Instead of inlining the required Facebook SDK Javascript wrapper
  code into the HTML, it now resides into its own .js file (served
  with ``{% static %}``). If you were using the builtin ``fbconnect.html``
  this change should go by unnoticed.


0.11.1 (2013-06-04)
*******************

Note worthy changes
-------------------

- Released (due to issue in disconnecting social accounts).

Backwards incompatible changes
------------------------------

None


0.11.0 (2013-06-02)
*******************

Note worthy changes
-------------------

- Moved logic whether or not a social account can be disconnected
  to the ``SocialAccountAdapter`` (``validate_disconnect``).

- Added ``social_account_removed`` signal.

- Implemented CSRF protection
  (http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-10.12).

- The ``user_logged_in`` signal now optionally receives a
  ``sociallogin`` parameter, in case of a social login.

- Added ``social_account_added`` (contributed by orblivion, thanks).

- Hatem Nassrat contributed Bitly support, thanks!

- Bojan Mihelac contributed a Croatian translation, thanks!

- Messages (as in ``django.contrib.messages``) are now configurable
  through templates.
- Added support for differentiating email handling (verification,
  required) between local and social accounts:
  ``SOCIALACCOUNT_EMAIL_REQUIRED`` and
  ``SOCIALACCOUNT_EMAIL_VERIFICATION``.


Backwards incompatible changes
------------------------------

None


0.10.1 (2013-04-16)
*******************

Note worthy changes
-------------------

- Cleaning of ``username`` can now be overridden via
  ``DefaultAccountAdapter.clean_username``

- Fixed potential error (``assert``) when connecting social
  accounts.

- Added support for custom username handling in case of custom
  user models (``ACCOUNT_USER_MODEL_USERNAME_FIELD``).


Backwards incompatible changes
------------------------------

None


0.10.0 (2013-04-12)
*******************

Note worthy changes
-------------------

- Chris Davis contributed Vimeo support, thanks!

- Added support for overriding the URL to return to after
  connecting a social account
  (``allauth.socialaccount.adapter.DefaultSocialAccountAdapter.get_connect_redirect_url``).

- Python 3 is now supported!

- Dropped dependency on (unmaintained?) oauth2 package, in favor
  of requests-oauthlib.

- account: Email confirmation mails generated at signup can now
  be differentiated from regular email confirmation mails by
  placing e.g. a welcome message into the
  ``account/email/email_confirmation_signup*`` templates. Thanks to
  Sam Solomon for the patch.

- account: Moved User instance creation to adapter so that e.g.
  username generation can be influenced. Thanks to John Bazik for
  the patch.

- Robert Balfre contributed Dropbox support, thanks!

- socialaccount: Added support for Weibo.

- account: Added support for sending HTML email. Add
  ``*_message.html`` templates and they will be automatically picked
  up.

- Added support for passing along extra parameters to the OAuth2
  authentication calls, such as ``access_type`` (Google) or
  ``auth_type`` (Facebook).
- Both the login and signup view now immediately redirect to the
  login redirect url in case the user was already authenticated.

- Added support for closing down signups in a pluggable fashion,
  making it easy to hookup your own invitation handling mechanism.

- Added support for passing along extra parameters to the
  ``FB.login`` API call.


Backwards incompatible changes
------------------------------

- Logout no longer happens on GET request. Refer to the ``LogoutView``
  documentation for more background information. Logging out on GET
  can be restored by the setting ``ACCOUNT_LOGOUT_ON_GET``. Furthermore,
  after logging out you are now redirected to
  ``ACCOUNT_LOGOUT_REDIRECT_URL`` instead of rendering the
  ``account/logout.html`` template.

- ``LOGIN_REDIRECT_URLNAME`` is now deprecated. Django 1.5 accepts both
  URL names and URLs for ``LOGIN_REDIRECT_URL``, so we do so as well.

- ``DefaultAccountAdapter.stash_email_verified`` is now named
  ``stash_verified_email``.

- Django 1.4.3 is now the minimal requirement.

- Dropped dependency on (unmaintained?) oauth2 package, in favor of
  requests-oauthlib. So you will need to update your (virtual)
  environment accordingly.

- We noticed a very rare bug that affects end users who add Google
  social login to existing accounts. The symptom is you end up with
  users who have multiple primary email addresses which conflicts
  with assumptions made by the code. In addition to fixing the code
  that allowed duplicates to occur, there is a management command
  you can run if you think this effects you (and if it doesn't effect
  you there is no harm in running it anyways if you are unsure):

  - ``python manage.py account_unsetmultipleprimaryemails``

    - Will silently remove primary flags for email addresses that
      aren't the same as ``user.email``.

    - If no primary ``EmailAddress`` is ``user.email`` it will pick one
      at random and print a warning.

- The expiry time, if any, is now stored in a new column
  ``SocialToken.expires_at``. Migrations are in place.

- Furthermore, Facebook started returning longer tokens, so the
  maximum token length was increased. Again, migrations are in place.

- Login and signup views have been turned into class-based views.

- The template variable ``facebook_perms`` is no longer passed to the
  "facebook/fbconnect.html" template. Instead, ``fb_login_options``
  containing all options is passed.


0.9.0 (2013-01-30)
******************

Note worthy changes
-------------------

- account: ``user_signed_up`` signal now emits an optional
  ``sociallogin`` parameter so that receivers can easily differentiate
  between local and social signups.

- account: Added ``email_removed`` signal.

- socialaccount: Populating of User model fields is now
  centralized in the adapter, splitting up ``name`` into ``first_name``
  and ``last_name`` if these were not individually available.

- Ahmet Emre Aladağ contributed a Turkish translation, thanks!

- socialaccount: Added SocialAccountAdapter hook to allow for
  intervention in social logins.

- google: support for Google's ``verified_email`` flag to determine
  whether or not to send confirmation emails.

- Fábio Santos contributed a Portuguese translation, thanks!

- socialaccount: Added support for Stack Exchange.

- socialaccount: Added ``get_social_accounts`` template tag.

- account: Default URL to redirect to after login can now be
  overridden via the adapter, both for login and email confirmation
  redirects.


Backwards incompatible changes
------------------------------

- ``requests`` is now a dependency (dropped ``httplib2``).

- Added a new column ``SocialApp.client_id``. The value of ``key`` needs
  to be moved to the new ``client_id`` column. The ``key`` column is
  required for Stack Exchange. Migrations are in place to handle all
  of this automatically.
