Let me start by saying I haven't read over this entire post (only
briefly on the initial thread).
For messages, why not switch these to using sessions? We have
implemented anonymous (on-demand) sessions locally, it could be very
useful to do this in general.
On Dec 19, 8:51 am, David Danier <[EM
> OK, so what you want is very very different from what I'm getting at here.
Yes and no, see below.
> What I want == newforms-admin can be run without django.contrib.auth,
> and people who do so understand that in doing so they are jettisoning
> anything which relies on django.contrib.auth.
Tru
On Dec 19, 2007 6:47 AM, David Danier <[EMAIL PROTECTED]> wrote:
> True, but having to duplicate every app in django.contrib I want to use
> (and which uses django.contrib.auth.models.User) only because the
> ForeignKey is wrong, that's bad in my opinion. And fixing the admin will
> not really hel
> If it is apocalyptically destructive to your application for there to
> be tables it doesn't use, then this is a problem.
Thats not really the problem, even if I don't really like it and don't
think it's what perfectionists like either.
> If you don't mind the fact that you won't be using the
On Dec 18, 2007 2:12 AM, David Danier <[EMAIL PROTECTED]> wrote:
> Correct me if I'm wrong, but doesn't this miss the big parts when
> writing your own auth-application. After adding this two methods the
> tables for LogEntry and Message still exist in the database, but are
> unusable. If you want
Sorry, i forgot this in my previous mail.
> I'm not particularly attached to these method names, but adding
> methods on ModelAdmin, say, log_action() and send_user_message(), and
> having the object-saving code call those methods instead of directly
> handling logging and messages, [...]
Everyb
> I'm not particularly attached to these method names, but adding
> methods on ModelAdmin, say, log_action() and send_user_message(), and
> having the object-saving code call those methods instead of directly
> handling logging and messages, would solve this pretty cleanly (and
> also add a little
On Dec 17, 2007 1:04 PM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> While playing around a bit with newforms-admin, I noticed that it's
> ever-so-close to being able to handle one cool use case which came up
> during the design discussion at PyCon: running django.contrib.admin
> without django.c
Joseph Kocherhans wrote:
> I don't want to speak for James, but that's how I see it.
Then this is great!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email t
On 2007-12-16 21:04:10 -0700, "James Bennett"
<[EMAIL PROTECTED]> said:
>
> While playing around a bit with newforms-admin, I noticed that it's
> ever-so-close to being able to handle one cool use case which came up
> during the design discussion at PyCon: running django.contrib.admin
> without
On 12/16/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> While playing around a bit with newforms-admin, I noticed that it's
> ever-so-close to being able to handle one cool use case which came up
> during the design discussion at PyCon: running django.contrib.admin
> without django.contrib.auth.
On 12/17/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> James Bennett wrote:
> > This means the default implementation can happily use
> > django.contrib.auth and the existing is_staff flag and permission
> > system, but that using something else is as easy as subclassing and
> > overriding the
James Bennett wrote:
> This means the default implementation can happily use
> django.contrib.auth and the existing is_staff flag and permission
> system, but that using something else is as easy as subclassing and
> overriding the right methods. And with a little refactoring to remove
> the direc
Doh! I just had a read through the dispatcher code and there's a lot
more going on there than I previously thought (possibly due to the
frequency of signal requests, like you mentioned).
On Dec 17, 3:52 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On Dec 17, 2007 3:39 AM, [EMAIL PROTECTED] <
On Dec 17, 2007 3:39 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Tell me if I'm crazy here, but what if LogEntry objects were created
> upon emission of some signal? That way, other apps could hook in and
> log their own actions as well, along with removing the admin's
> dependency on auth
Tell me if I'm crazy here, but what if LogEntry objects were created
upon emission of some signal? That way, other apps could hook in and
log their own actions as well, along with removing the admin's
dependency on auth. It could go into django.contrib.logging or
something.
What do you guys thi
On 17 Dec 2007, at 08:08, James Bennett wrote:
> This means the default implementation can happily use
> django.contrib.auth and the existing is_staff flag and permission
> system, but that using something else is as easy as subclassing and
> overriding the right methods. And with a little refac
On Dec 17, 2007 1:34 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> I'm either confused or scared. Presumably the admin application still
> relies on authentication, right? Without making me rustle through all
> the code, can you explain how it is enforcing access restrictions
> without the a
On Sun, 2007-12-16 at 22:04 -0600, James Bennett wrote:
> While playing around a bit with newforms-admin, I noticed that it's
> ever-so-close to being able to handle one cool use case which came up
> during the design discussion at PyCon: running django.contrib.admin
> without django.contrib.auth
While playing around a bit with newforms-admin, I noticed that it's
ever-so-close to being able to handle one cool use case which came up
during the design discussion at PyCon: running django.contrib.admin
without django.contrib.auth.
The implemention of has_permission() on AdminSite, and
has_(ad
20 matches
Mail list logo
