newforms-admin: Merged from trunk up to [7602].

git-svn-id: http://code.djangoproject.com/svn/django/branches/newforms-admin@7604 bcc190cf-cafb-0310-a4f2-bffc1f526a37

5 files changed, 223 insertions, 11 deletions

diff --git a/docs/authentication.txt b/docs/authentication.txt
index 28e73faba7..00cb8e45ca 100644
--- a/docs/authentication.txt
+++ b/docs/authentication.txt
@@ -263,14 +263,25 @@ Creating superusers
 -------------------
 
 ``manage.py syncdb`` prompts you to create a superuser the first time you run
-it after adding ``'django.contrib.auth'`` to your ``INSTALLED_APPS``. But if
-you need to create a superuser after that via the command line, you can use the
-``create_superuser.py`` utility. Just run this command::
+it after adding ``'django.contrib.auth'`` to your ``INSTALLED_APPS``. If you need
+to create a superuser at a later date, you can use a command line utility.
+
+**New in Django development version.**::
+
+    manage.py createsuperuser --username=joe --email=joe@example.com
+
+You will be prompted for a password. Once entered, the user is created. If you
+leave off the ``--username`` or the ``--email`` option, It will prompt you for
+those values as well.
+
+If you're using an older release of Django, the old way of creating a superuser
+on the command line still works::
 
     python /path/to/django/contrib/auth/create_superuser.py
 
-Make sure to substitute ``/path/to/`` with the path to the Django codebase on
-your filesystem.
+Where ``/path/to`` is the path to the Django codebase on your filesystem. The
+``manage.py`` command is prefered since it'll figure out the correct path and
+environment for you.
 
 Storing additional information about users
 ------------------------------------------
diff --git a/docs/django-admin.txt b/docs/django-admin.txt
index e79c105bbd..5aed3b0816 100644
--- a/docs/django-admin.txt
+++ b/docs/django-admin.txt
@@ -109,6 +109,31 @@ the program name (``psql``, ``mysql``, ``sqlite3``) will find the program in
 the right place. There's no way to specify the location of the program
 manually.
 
+createsuperuser
+---------------
+
+**New in Django development version**
+
+Creates a superuser account (a user who has all permissions). This is
+useful if you need to create an initial superuser account but did not
+do so during ``syncdb``, or if you need to programmatically generate
+superuser accounts for your site(s).
+
+When run interactively, this command will prompt for a password for
+the new superuser account; when run non-interactively, no password
+will be set and the superuser account will not be able to log in until
+a password has been manually set for it.
+
+The username and e-mail address for the new account can be supplied by
+using the ``--username`` and ``--email`` arguments on the command
+line; if not supplied, ``createsuperuser`` will prompt for them when
+running interactively.
+
+This command is only available if Django's `authentication system`_
+(``django.contrib.auth``) is installed.
+
+.. _authentication system: ../authentication/
+
 diffsettings
 ------------
 
diff --git a/docs/faq.txt b/docs/faq.txt
index 56c9536eda..5e36f1d933 100644
--- a/docs/faq.txt
+++ b/docs/faq.txt
@@ -228,13 +228,14 @@ Short answer: When we're comfortable with Django's APIs, have added all
 features that we feel are necessary to earn a "1.0" status, and are ready to
 begin maintaining backwards compatibility. 
 
-The merging of Django's `magic-removal branch`_ went a long way toward Django
-1.0.
+The merging of Django's `Queryset Refactor branch`_ went a long way toward Django
+1.0. Merging the `Newforms Admin branch` will be another important step.
 
 Of course, you should note that `quite a few production sites`_ use Django in
 its current status. Don't let the lack of a 1.0 turn you off.
 
-.. _magic-removal branch: http://code.djangoproject.com/wiki/RemovingTheMagic
+.. _Queryset Refactor branch: http://code.djangoproject.com/wiki/QuerysetRefactorBranch
+.. _Newforms Admin branch: http://code.djangoproject.com/wiki/NewformsAdminBranch
 .. _quite a few production sites: http://code.djangoproject.com/wiki/DjangoPoweredSites
 
 How can I download the Django documentation to read it offline?
@@ -259,7 +260,9 @@ Where can I find Django developers for hire?
 Consult our `developers for hire page`_ for a list of Django developers who
 would be happy to help you.
 
-You might also be interested in posting a job to http://www.gypsyjobs.com/ .
+You might also be interested in posting a job to http://djangogigs.com/ . 
+If you want to find Django-capable people in your local area, try 
+http://djangopeople.net/ .
 
 .. _developers for hire page: http://code.djangoproject.com/wiki/DevelopersForHire
 
@@ -643,6 +646,81 @@ You can also use the Python API. See `creating users`_ for full info.
 
 .. _creating users: ../authentication/#creating-users
 
+Getting Help
+============
+
+How do I do X? Why doesn't Y work? Where can I go to get help?
+--------------------------------------------------------------
+
+If this FAQ doesn't contain an answer to your question, you might want to
+try the `django-users mailing list`_. Feel free to ask any question related 
+to installing, using, or debugging Django. 
+
+If you prefer IRC, the `#django IRC channel`_ on freenode is an active
+community of helpful individuals who may be able to solve your problem. 
+
+.. _`django-users mailing list`: http://groups.google.com/group/django-users
+.. _`#django IRC channel`: irc://irc.freenode.net/django
+
+Why hasn't my message appeared on django-users?
+-----------------------------------------------
+
+django-users_ has a lot of subscribers. This is good for the community, as
+there are lot of people that can contribute answers to questions.
+Unfortunately, it also means that django-users_ is an attractive target for
+spammers. 
+
+In order to combat the spam problem, when you join the django-users_ mailing
+list, we manually moderate the first message you send to the list. This means 
+that spammers get caught, but it also means that your first question to the 
+list might take a little longer to get answered. We apologize for any
+inconvenience that this policy may cause.
+
+.. _django-users: http://groups.google.com/group/django-users
+
+Nobody on django-users answered my question? What should I do?
+--------------------------------------------------------------
+
+Wait. Ask again later. Try making your question more specific, or provide
+a better example of your problem.
+
+Remember, the readers of django-users_ are all volunteers. If nobody has
+answered your question, it may be because nobody knows the answer, it may
+be because nobody can understand the question, or it may be that everybody
+that can help is extremely busy.
+
+Resist any temptation to mail the `django-developers mailing list`_ in an 
+attempt to get an answer to your question. django-developers_ is for discussing 
+the development of Django itself. Attempts to use django-developers_ as
+a second-tier support mechanism will not be met an enthusiastic response.
+
+.. _`django-developers mailing list`: http://groups.google.com/group/django-developers
+.. _django-developers: http://groups.google.com/group/django-developers
+
+I think I've found a bug! What should I do?
+-------------------------------------------
+
+Detailed instructions on how to handle a potential bug can be found in our
+`Guide to contributing to Django`_.
+
+.. _`Guide to contributing to Django`: ../contributing/#reporting-bugs
+
+I think I've found a security problem! What should I do?
+--------------------------------------------------------
+
+If you think you have found a security problem with Django, please send 
+a message to security@djangoproject.com. This is a private list only
+open to long-time, highly trusted Django developers, and its archives 
+are not publicly readable. 
+
+Due to the sensitive nature of security issues, we ask that if you think you
+have found a security problem, *please* don't send a message to one of the 
+public mailing lists. Django has a `policy for handling security issues`_;
+while a defect is outstanding, we would like to minimize any damage that 
+could be inflicted through public knowledge of that defect.
+
+.. _`policy for handling security issues`: ../contributing/#reporting-security-issues
+
 Contributing code
 =================
 
@@ -652,7 +730,7 @@ How can I get started contributing code to Django?
 Thanks for asking! We've written an entire document devoted to this question.
 It's titled `Contributing to Django`_.
 
-.. _Contributing to Django: ../contributing/
+.. _`Contributing to Django`: ../contributing/
 
 I submitted a bug fix in the ticket system several weeks ago. Why are you ignoring my patch?
 --------------------------------------------------------------------------------------------
@@ -664,6 +742,11 @@ ignored" and "a ticket has not been attended to yet." Django's ticket system
 contains hundreds of open tickets, of various degrees of impact on end-user
 functionality, and Django's developers have to review and prioritize.
 
+On top of that - the team working on Django are all volunteers. As a result, 
+the amount of time that we have to work on Django is limited, and will vary
+from week to week depending on how much spare time we have. If we are busy, we
+may not be able to spend as much time on Django as we might want.
+
 Besides, if your feature request stands no chance of inclusion in Django, we
 won't ignore it -- we'll just close the ticket. So if your ticket is still
 open, it doesn't mean we're ignoring you; it just means we haven't had time to
diff --git a/docs/serialization.txt b/docs/serialization.txt
index 8a672d8b8a..2a3e7038da 100644
--- a/docs/serialization.txt
+++ b/docs/serialization.txt
@@ -63,6 +63,41 @@ be serialized.
     doesn't specify all the fields that are required by a model, the deserializer
     will not be able to save deserialized instances.
 
+Inherited Models
+~~~~~~~~~~~~~~~~
+
+If you have a model that is defined using an `abstract base class`_, you don't
+have to do anything special to serialize that model. Just call the serializer
+on the object (or objects) that you want to serialize, and the output will be
+a complete representation of the serialized object.
+
+However, if you have a model that uses `multi-table inheritance`_, you also
+need to serialize all of the base classes for the model. This is because only
+the fields that are locally defined on the model will be serialized. For
+example, consider the following models::
+	
+	class Place(models.Model):
+		name = models.CharField(max_length=50)
+		
+	class Restaurant(Place):
+		serves_hot_dogs = models.BooleanField()
+		
+If you only serialize the Restaurant model::
+
+	data = serializers.serialize('xml', Restaurant.objects.all())
+
+the fields on the serialized output will only contain the `serves_hot_dogs`
+attribute. The `name` attribute of the base class will be ignored.
+
+In order to fully serialize your Restaurant instances, you will need to
+serialize the Place models as well::
+
+	all_objects = list(Restaurant.objects.all()) + list(Place.objects.all())
+	data = serializers.serialize('xml', all_objects)
+
+.. _abstract base class: http://www.djangoproject.com/documentation/model-api/#abstract-base-classes
+.. _multi-table inheritance: http://www.djangoproject.com/documentation/model-api/#multi-table-inheritance
+
 Deserializing data
 ------------------
 
diff --git a/docs/sessions.txt b/docs/sessions.txt
index d8bac5b8d4..86ed49f135 100644
--- a/docs/sessions.txt
+++ b/docs/sessions.txt
@@ -80,19 +80,24 @@ attribute, which is a dictionary-like object. You can read it and write to it.
 It implements the following standard dictionary methods:
 
     * ``__getitem__(key)``
+
       Example: ``fav_color = request.session['fav_color']``
 
     * ``__setitem__(key, value)``
+
       Example: ``request.session['fav_color'] = 'blue'``
 
     * ``__delitem__(key)``
+
       Example: ``del request.session['fav_color']``. This raises ``KeyError``
       if the given ``key`` isn't already in the session.
 
     * ``__contains__(key)``
+
       Example: ``'fav_color' in request.session``
 
     * ``get(key, default=None)``
+
       Example: ``fav_color = request.session.get('fav_color', 'red')``
 
     * ``keys()``
@@ -101,23 +106,70 @@ It implements the following standard dictionary methods:
 
     * ``setdefault()`` (**New in Django development version**)
 
-It also has these three methods:
+It also has these methods:
 
     * ``set_test_cookie()``
+
       Sets a test cookie to determine whether the user's browser supports
       cookies. Due to the way cookies work, you won't be able to test this
       until the user's next page request. See "Setting test cookies" below for
       more information.
 
     * ``test_cookie_worked()``
+
       Returns either ``True`` or ``False``, depending on whether the user's
       browser accepted the test cookie. Due to the way cookies work, you'll
       have to call ``set_test_cookie()`` on a previous, separate page request.
       See "Setting test cookies" below for more information.
 
     * ``delete_test_cookie()``
+
       Deletes the test cookie. Use this to clean up after yourself.
 
+    * ``set_expiry(value)``
+
+      **New in Django development version**
+
+      Sets the expiration time for the session. You can pass a number of
+      different values:
+
+            * If ``value`` is an integer, the session will expire after that
+              many seconds of inactivity. For example, calling
+              ``request.session.set_expiry(300)`` would make the session expire
+              in 5 minutes.
+
+            * If ``value`` is a ``datetime`` or ``timedelta`` object, the
+              session will expire at that specific time.
+      
+            * If ``value`` is ``0`` then the user's session cookie will expire
+              when their browser is closed.
+
+            * If ``value`` is ``None``, the session reverts to using the global
+              session expiry policy.
+
+    * ``get_expiry_age()``
+
+      **New in Django development version**
+
+      Returns the number of seconds until this session expires. For sessions
+      with no custom expiration (or those set to expire at browser close), this
+      will equal ``settings.SESSION_COOKIE_AGE``.
+
+    * ``get_expiry_date()``
+
+      **New in Django development version**
+
+      Returns the date this session will expire. For sessions with no custom
+      expiration (or those set to expire at browser close), this will equal the
+      date ``settings.SESSION_COOKIE_AGE`` seconds from now.
+
+    * ``get_expire_at_browser_close()``
+
+      **New in Django development version**
+
+      Returns either ``True`` or ``False``, depending on whether the user's
+      session cookie will expire when their browser is closed.
+
 You can edit ``request.session`` at any point in your view. You can edit it
 multiple times.
 
@@ -278,6 +330,12 @@ browser-length cookies -- cookies that expire as soon as the user closes his or
 her browser. Use this if you want people to have to log in every time they open
 a browser.
 
+**New in Django development version**
+
+This setting is a global default and can be overwritten at a per-session level
+by explicitly calling ``request.session.set_expiry()`` as described above in
+`using sessions in views`_.
+
 Clearing the session table
 ==========================