Changes between Version 19 and Version 20 of SummerOfCode2011

Timestamp:

Mar 30, 2011, 4:47:33 PM (14 years ago)

Author:

Aymeric Augustin

Comment:

--

SummerOfCode2011

@@ -262 +262 @@
  * How will you deal with a lack of features in various backends? South has workarounds for some, but others, such as properly managing indexes, are very difficult.
  * How will you make sure the new API is flexible enough to work with not just South, but other current and future migration frameworks?
+
+=== Integrate databrowse into the admin ===
+* '''Complexity:''' Medium
+
+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.''
+
+The first lines of the [http://docs.djangoproject.com/en/dev/ref/contrib/databrowse/ docs for databrowse] highlight the current situation:
+- 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,
+- 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.
+Given this situation, there is a consensus — at least today in #django-dev — to pull databrowse out of Django.
+
+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".
+
+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.
+Then you will see what is missing from the current admin to reach equivalent functionality.
+The most obvious points are:
+ * The "automatic browsability": date-based filters, automatic linking to related models, etc. These are possible in the admin but require code.
+ * 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.
+
+The following issues should be considered:
+ * How can you improve the "browsability" of the admin (explore/show mode) while keeping it efficient as an edition interface (find/edit mode)?
+ * 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)?
+ * How will you provide a simple migration path for existing databrowse users?