On Fri, Jul 2, 2010 at 7:03 PM, Helgi Borg <[email protected]> wrote: > Remember the Eyjafjallajökull eruption that stopped air traffic over > parts of Europe? The staff at the Icelandic Meterological Office had > a seriously busy time the first days of the eruption. When I arrived > at work the first morning, I quickly realized that we needed a simple > msg-software so the teams of meteorologists, geologists, hydrographers > and the executives could better synchronize their work. In a few > hours, I had implemented, tested and deployed a Django app that helped > a lot. - Django is truly an amazing piece of software. Thank you for > Django!
You're most welcome - and thanks for sharing your story. We've been meaning to start gathering success stories so that we can show the world all the interesting ways and places that Django is used. It would be fantastic to be able to tell the world about success stories such as yours. > The Django app was reasonable good although not perfect. Let me > explain why… > > I needed every user to be able to view messages from anyone. Members > of the same teams (users of the same Auth. group) needed to be able to > correct messages from each other for some time until the messages > automatically locked for changes. > > The obvious choose was to use the Contrib Admin. It is robust, fast, > easy for developers to use, easy for users to get used to and has a > persistent user interface. In other words it is almost perfect for all > our data registration usage except that it doesn’t have view > permissions. The ModelAdmin class would be perfect if it only had view > permissions (perhaps read permission is a better word). > > A dirty solution is to apply change permission to “view only > permission-users” and then use save_model() to deny these users to > actually change view-only instances. The practical problem with this > is that the UI indicates that the user can change something that he/ > she may not change. > > One could argue that I should use something else than Contrib Admin. > The problem is that there is nothing else as good available. Mixing > Contrib Admin with other app for view-only purposes results in bad > usability. Further it doesn’t adhere to the DRY principle to create > something new when you have something as good as Contrib Admin. > > I’ve also created other apps where I’ve needed view permission. These > are Avalanche registration, Registration of ash fall, Sea ice > registration, Warning registration and Weather forecasters self > quality monitoring. Other apps will most likely follow. > > I would really appreciate if you could answer the following questions: > 1) Is there any change that you might consider adding view permissions > to the Contrib Admin? > 2) If not, may I ask what the reason is? The idea has been proposed in the past: [1] http://code.djangoproject.com/ticket/820 [2] http://code.djangoproject.com/ticket/7150 As you can see from those tickets, the historical position has been to reject the idea. However, it also hasn't been a subject of serious discussion for a couple of years. There have been a couple of changes in recent history that suggest to me that there might be scope to revisit this area -- more details below. > 3) Can I add view permissions functionality on top of the Contrib > Admin without changing its interior, thus avoiding problems on next > Django update? You can always add new permissions without any risk. Django's docs describe how extra permissions can be defined in the Meta block of a model [3], but a permission is ultimately just an Django object itself, so you can create custom permissions manually or programmatically if you want. [3] http://docs.djangoproject.com/en/1.2/topics/auth/#id2 However, the admin will only honor the add/edit/delete permissions by default. If you want admin to honor your custom view permissions, you'll need to add custom readonly views that check for that permission. Luckily, you can also add custom views to a standard Admin install without risk. ModelAdmin allows you to provide a get_urls() method that exposes custom views. Josh Ourisman's blog post (see his reply on this thread) shows how this can be done. > 4) If not, are there many changes planned for the Contrib Admin on > next release -- would it be wise for me to add it my self? We're still in the process of working out what we will be adding to Django 1.3, so at the moment, there aren't any firm plans. However, the broad intention of Django 1.3 is to concentrate less on big features, and more on bug fixes and smaller features. That doesn't mean we're not going to add new features -- just that the intention is to focus less on big features (like multiple database support), and more on bug fixes. That said, ultimately we'll consider any patch that implements a trunk-ready feature for inclusion in trunk. Concerning the historical reluctance to add view permissions: Django 1.2 added two features that lead me to believe that the time may have come to revisit the earlier decisions to avoid view permissions. Firstly, we added readonly fields. Ultimately, a readonly view is just a view where all the fields are readonly; to me, it seems like a small jump from "specifying an admin with N readonly fields" to "specifying an admin that is all readonly fields". Secondly, we added a framework for per-object permissions. Although the API is in place for this, I'm not convinced that the consequences of this change have been fully reflected in the admin. After all, it's now possible to have a list of objects, but only have access to edit some of those objects - but that doesn't mean you can't *see* the remaining object - especially in the context of foreign key relations. So -- I'm at least willing to entertain the discussion about adding this as a first-class feature of the admin. If this is a feature that you are enthused by, then put together a full proposal describing exactly what you would like to add (possibly with a prototype patch), and we can have the discussion over whether we should add this feature to trunk -- or whether, like with per-object permissions, we just need to expose an better API to make it easier to add view permissions as an end-user. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
