Currently The `TIME_ZONE` Django setting allows PostgreSQL-backed installations to run project/application on timezones different from each other and from the system timezone of the server.

117

Also, the information of !DateTime fields is retrieved from the database as naïve Python `datetime` instances and when the DB backend is PostgreSQL the data sent and retrieved to/from the DB is corrected by the `TIME_ZONE` value.

118

119

But if you need to have:

120

121

* date+time data to be entered in different locations using the local time

122

* such data be displayed in the local time at different locations different from the location where it was originally entered.

123

124

then more granularity is needed so different instances of date+time inside one application can be handled in a way that takes in account its timezone.

125

126

An additional possibility would to create an additional presentation layer, where an user location/timezone preference can influence and personalize the display of date+time's (see the Django template filter idea in one of the thread linked below.)

127

128

Other advantages of a solution to this problem could be: Isolation from daylight saving time political policy changes and isolation from changes on time zones should the hosting of a production application be moved form one geographical location to another.

129

130

Issues to consider:

131

* Compatibility with all the DB backend officially supported by Django

Django has an extensive test framework for Python code, a suite of tools to make server-side testing easier, and a project policy that no new code is added without tests. This has been a significant contributor to the stability of Django as a project.

220

191

221

However, Django also has client-side components, and these are not tested. Django doesn't currently have any systematic way to test Javascript. As a result, large parts of Django's public-facing code are not tested, and are prone to regressions and failures -- most notably, Django's admin, and the handling of inline form elements.

222

223

We need a set of tools that allow us to test the Javascript code that forms part of Django's codebase, and a set of tests to validate the behavior of contrib.admin's widgets (and other admin components).

224

225

Issues to consider:

226

* How to handle cross-browser differences? Should we use a tool like Selenium to do live tests, or write genuine unit tests of Javascript as a scripting language?

227

* How to clearly identify javascript tests at runtime? It should be possible to "just run the GUI tests" or "just run the code tests". This may tie into a broader requirement to differentiate "integration tests" (which validate that an app is installed correctly) from "system tests" (which validate that an app works correctly internally)

228

229

See also:

230

* #15569 and #14303 (a series of bugs and regressions that should have been caught and tested)

231

* #2879

232

* #13873

192

For the 1.4 release, we also included the basis of a client-side testing framework into Django (https://docs.djangoproject.com/en/dev/topics/testing/#django.test.LiveServerTestCase)

193

194

However, this now means that Django has a very large and powerful test suite without much separation or control from a user's perspective, so the goal of this project would be to add new options and suite types to allow running of specific types of tests, be they only a certain class (e.g. unit-tests only) or excluding tests (such as the ones in contrib or third-party apps) from the main test run easily.

195

196

Issues to consider:

197

* How would users declare which tests they want to run?

198

* Which tests should be enabled by default, and how hard should this be to change?

199

* How will it be app maintainers run their tests?

200

* Should there be additional hooks to, for example, allow tests to be run against different database backends in sequence?

* How will you make sure the new API is flexible enough to work with not just South, but other current and future migration frameworks?

247

219

248

=== Integrate databrowse into the admin ===

220

221

=== Finishing off the App Refactor ===

249

222

* '''Complexity:''' Medium

250

223

251

The BDFLs of Django suggested merging databrowse into the admin two years ago: see #8936. Jacob stated the goals clearly on #django-dev today: ''<jacobkm> Personally, I think merging the functionality into the admin would be pretty awesome -- it'd get rid of mostly vestigal code, and it'd also provide a feature ("read permissions") that people have been clamoring for for ages.''

252

253

The first lines of the [http://docs.djangoproject.com/en/dev/ref/contrib/databrowse/ docs for databrowse] highlight the current situation:

254

- the second sentence, while attempting to illustrate the difference between the purposes of the admin and of databrowse, actually shows that they are very similar,

255

- the app is described as new and unstable, and at the same time it suffers from several [http://code.djangoproject.com/query?status=!closed&component=contrib.databrowse long-standing, sometimes trivial, bugs], showing a lack of maintenance.

256

Given this situation, there is a consensus — at least today in #django-dev — to pull databrowse out of Django.

257

258

Merging databrowse into the admin would also resolve a common complaint: currently, there is no easy way to give a read-only access to the admin. Available permissions include "add", "change", "delete" but not "view".

259

260

The first step is to evaluate precisely the functionality that databrowse provides. The docs only show how to configure it, so reading the source and experimenting is important.

261

Then you will see what is missing from the current admin to reach equivalent functionality.

262

The most obvious points are:

263

* The "automatic browsability": date-based filters, automatic linking to related models, etc. These are possible in the admin but require code.

264

* The read only permissions. The concept is fairly simple. A good implementation should take care to hide all edition-related UI elements for users that do not have write permissions. Expressing this cleanly within the current admin app will require some work.

265

266

The following issues should be considered:

267

* How can you improve the "browsability" of the admin (explore/show mode) while keeping it efficient as an edition interface (find/edit mode)?

268

* How can you implement the "automatic browsability" described above while preserving the possibility to customize the display, like the current admin (fields, fieldsets, list_display, list_filter and friends)?

269

* How will you provide a simple migration path for existing databrowse users?

270

271

=== Py3K Support ===

224

In a previous GSOC (2010) a project to refactor Django's internal structure for representing and loading apps was started, and continued by Jannis into 2011: https://github.com/jezdez/django/commits/app-loading

225

226

However, this branch is still a little way away from being merged, and so the task for this GSOC project would be to finish off the work on the branch and prepare it for a merge into trunk. The change touches quite a few different areas of the codebase (see the current diff: https://github.com/jezdez/django/compare/master...app-loading) and so you'll have to get familiar with each in order to ensure everything runs smoothly.

227

228

=== Finishing off Form Templates ===

272

229

* '''Complexity:''' Medium

273

230

274

Add Python 3 support to Django. You'd be responsible for surveying the existing work (Martin van Loewis's and Greg Wilson's students'), and modifying Django to run under Python 3. Likely using ``lib2to3``, but figuring that out is your job. Your target is to get as much of the test suite passing as possible. If you choose to use ``lib2to3`` you may end up developing some fixers for our end users to use as well. Maintainability of the source code for the present developers is a huge goal for you.

231

Last year, a GSOC project worked on replacing the internal Django code that renders forms with a templated system, allowing for much better flexibility and customisability of forms, fields, and related components in the forms framework. The current code can be found here: https://github.com/gregmuellegger/django/commits/soc2011/form-rendering

232

233

One of the main issues with the branch last year was that the template renderer was not fast enough on large numbers of includes and extends, meaning that the new form templates, while modular, were slower than the current forms system. One of the main tasks will thus be to investigate, and hopefully implement, ways to improve the rendering speed of the form templates.