forked from macropin/django-registration
-
Notifications
You must be signed in to change notification settings - Fork 0
/
CHANGELOG
327 lines (207 loc) · 9.9 KB
/
CHANGELOG
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
===================================
django-registration-redux changelog
===================================
Version 1.2, 11 May, 2015
-------------------------
* BACKWARDS-INCOMPATIBLE CHANGE: When overriding the
`registration/activation_email.txt` template, you must also now override the
`registration/activation_email.html` template or set the setting
(`REGISTRATION_EMAIL_HTML`) to `False`.
* BACKWARDS-INCOMPATIBLE CHANGE: An initial migration for Django > 1.7 has been
provided. South users will need to configure a null migration with
(`SOUTH_MIGRATION_MODULES`).
* BACKWARDS-INCOMPATIBLE CHANGE: A `base.html` template is now assumed to
exist.
* Feature: Added support for disabling HTML emails using the setting option
`REGISTRATION_EMAIL_HTML`.
* Feature: Added settings' options that allows to exlude the default auth urls
(`INCLUDE_AUTH_URLS`) and register url (`INCLUDE_REGISTER_URL`).
* Feature: Added support to dynamically import any chosen registration form
using the settings option `REGISTRATION_FORM`.
* Enhancement: Make `RegistrationForm` a subclass of Django's
`UserCreationForm`
* Enhancement: Use registration form `save` method to create user instance,
whenever form is a subclass of Django's `ModelForm`.
Version 1.1, 19 September, 2014
-------------------------------
This represents the first release of `django-registration-redux`.
It is based off the defunct v1.0 `django-registration` abandoned by James Bennett.
* Compatibility: Added support for Python 3.x.
* Compatibility: Added support for Django 1.6, 1.7.
* Feature: Added support for mime/multipart HTML / Text registration
emails.
* Feature: Added `REGISTRATION_EMAIL_SUBJECT_PREFIX` config.
* Feature: Added support for `REGISTRATION_AUTO_LOGIN` config.
* Feature: Added support for `SEND_ACTIVATION_EMAIL` config.
* Bugfix: Signal "user_activated" was being sent twice.
* Bugfix: Fixed broken tests.
The change log below is from the versions maintained
by James Bennett.
Version 1.0, 17 June 2013
-------------------------
(Taken from release-notes.rst in this release)
* The 1.0 release of django-registration represents a complete
rewrite of the previous codebase. For information on upgrading,
consult :ref:`the upgrade guide <upgrade>`.
* The largest overall change is that in place of the monolithic backend
classes and function-based views found in django-registration 0.8, in
1.0 all views are class-based. A "backend" now consists of,
typically, one or two subclasses of :ref:`the built-in base views
<views>`.
* Implementing these as class-based views allows for far simpler
configuration and customization, without the overhead involved in
supporting large numbers of optional keyword arguments to
function-based views, or the need to provide a separate class-based
infrastructure for implementing the logic of registration.
* Notably, this implementation is also completely backwards-compatible
for users of django-registration 0.8 who simply used the recommended
default URLConf for one of the supplied backends; those URLConfs exist
in the same locations, and have been rewritten to point to the
appropriate class-based views with the appropriate options.
Version 0.8, 24 March 2012:
---------------------------
* Backend-based rewrite. See docs/upgrade.rst for details.
* Compatibility through Django 1.4.
Version 0.7, 6 November 2008:
-----------------------------
* Project hosting moved from Google Code to Bitbucket, and from a
Subversion repository to Mercurial.
* Added test suite.
* Full Django 1.0 compatibility.
* Registration and activation views now accept an ``extra_context``
argument, identical to the way that argument works in Django's
generic views.
* Added a custom management command for cleaning up expired
registrations; you can now run ``manage.py cleanupregistration`` to
handle this.
* BACKWARDS-INCOMPATIBLE CHANGE: The "username" field in
``RegistrationForm`` is now a ``RegexField``.
* BACKWARDS-INCOMPATIBLE CHANGE: Removed the standalone script for
deleting expired user registrations; use the new management command
instead.
Version 0.6, 29 July 2008:
--------------------------
* Packaged from revision 166 in Subversion.
* Fixed a multiple-objects exception in
``RegistrationFormUniqueEmail`` when multiple users already have the
same email address.
* Changed the ``success_url`` of the ``register()`` view to use
reverse URL resolution.
* Added an ``extra_context`` argument to the ``register`` and
``activate`` views, mimicking its functionality in Django's generic
views.
* BACKWARDS-INCOMPATIBLE CHANGE: Switched the admin declaration to be
compliant with the newforms-admin refactor; the admin declaration
now lives in ``registration/admin.py``.
* BACKWARDS-INCOMPATIBLE CHANGE: Switched form imports from using
``django.newforms`` to using ``django.forms``; the old style now
raises a deprecation warning on Django trunk and on Django 1.0
alpha.
Version 0.5, 4 June 2008:
-------------------------
* Packaged from revision 155 in Subversion.
* Added Serbian translation.
* Added Italian translation.
* Username/email uniqueness checks are now case-insensitive. This is
potentially backwards-incompatible if you relied on them being
case-sensitive, but I don't know of any reason why you'd be doing
that.
* Included forms now use lazy translations.
* The ``register`` view can now handle files submitted for use in form
processing.
* Reactivation of a manually-deactivated account is now prevented by
changing the activation key, on successful activation, to a dummy
string which will fail on subsequent activation attempts.
Version 0.4p2, 10 Feburary 2008:
--------------------------------
* Added Brazilian Portuguese translation.
* Added Japanese translation.
* Added Hebrew translation.
* Minor documentation fixes.
Version 0.4p1, 16 December 2007:
--------------------------------
* Packaged from revision 129 in Subversion.
* Added Polish translation.
Version 0.4, 8 December 2007:
-----------------------------
* Packaged from revision 122 in Subversion.
* Added Greek translation.
* Added Russian translation.
* Changed ``maxlength`` to ``max_length`` now that Django issues a
deprecation warning for it.
* BACKWARDS-INCOMPATIBLE CHANGE: Changed the password validation to be
on ``clean()`` instead of ``clean_password2()``. This means that
errors from this must be accessed via ``non_field_errors()``.
Version 0.3p5, 6 October 2007:
------------------------------
* Packaged from revision 112 in Subversion.
* Added German translation.
* Fixed a mismatch between the default ``RegistrationForm``'s maximum
length on email addresses and the actual maximum length on Django's
``User`` model.
* Fixed a situation where bad input for the ``password1`` field on
``RegistrationForm`` could cause validation of ``password2`` to fail
with an exception.
Version 0.3p4, 4 October 2007:
------------------------------
* Packaged from revision 101 in Subversion.
* BACKWARDS-INCOMPATIBLE CHANGE: In response to larger numbers of
complaints from people trying to use the example templates as-is,
the example templates have been removed.
Version 0.3p2, 23 September 2007:
---------------------------------
* Packaged from revision 100 in Subversion.
* Fixed ``activate`` view to actually take the ``template_name``
argument.
Version 0.3p1, 22 September 2007:
---------------------------------
* Packaged from revision 99 in Subversion.
* Fixed a typo in docs/overview.txt.
* Fixed a typo in bin/delete_expired_users.py.
* Added French translation.
Version 0.3, 19 September 2007:
-------------------------------
Packaged from revision 89 in Subversion; download at
http://django-registration.googlecode.com/files/registration-0.3.tar.gz
* Changed ``register`` and ``activate`` views to accept
``template_name`` keyword argument for selecting a custom template.
* Changed ``register`` view to accept ``form_class`` keyword
argument specifying the form to use.
* BACKWARDS-INCOMPATIBLE CHANGE: Changed
``RegistrationManager.create_inactive_user`` to use a template for
the subject of the activation email.
* BACKWARDS-INCOMPATIBLE CHANGE: Removed the ``tos`` field from
``RegistrationForm``; if you were relying on it, switch to using
``RegistrationFormTermsOfService`` instead.
* BACKWARDS-INCOMPATIBLE CHANGE: The activation email template now
receives the current ``Site`` object as the context variable
``site``, and the ``current_site`` variable, which only held the
domain, is no longer available.
* Added script ``bin/delete_expired_users.py`` with instructions on
how to use it as a cron job to clean up expired/inactive accounts.
* Marked strings for translation and added ``locale`` directory so
that translations can be added.
* Updated to deal with merge of Django's Unicode branch into trunk;
now using Unicode-aware functions everywhere.
Version 0.2, 29 May 2007:
-------------------------
Packaged from revision 76 in Subversion; download at
http://django-registration.googlecode.com/files/registration-0.2.tar.gz
* Added ability to specify a callback in
``RegistrationManager.create_inactive_user`` or in the ``register``
view to enable creation of site-specific user profile.
* Separated out the logic of creating the profile into a new method on
``RegistrationManager``: ``create_profile``.
* Added URLConf support for various useful views in
``django.contrib.auth``.
* BACKWARDS-INCOMPATIBLE CHANGE: removed the ``key_generated`` field
from ``RegistrationProfile``; activation key expiration is now
calculated based on the ``date_joined`` field in the ``User`` model.
Drop the ``key_generated`` column from your database when upgrading
from 0.1.
Version 0.1, 23 May 2007:
-------------------------
Packaged from revision 56 in Subversion; download at
http://django-registration.googlecode.com/files/registration-0.1.tar.gz
* First packaged version using distutils.
* Added docs/ directory and overview.