On 1/23/06, Maniac <[EMAIL PROTECTED]> wrote:
>
> Joseph Kocherhans wrote:
>
> >Have you started on this yet maniac?
> >
> Not yet. And actually can't predict when I'll be able to :-(. So feel
> free to implement the idea if you like. Please post here a ticket number
> to track the thing.
I've ad
Joseph Kocherhans wrote:
Have you started on this yet maniac?
Not yet. And actually can't predict when I'll be able to :-(. So feel
free to implement the idea if you like. Please post here a ticket number
to track the thing.
On 1/11/06, Maniac <[EMAIL PROTECTED]> wrote:
>
> Adrian Holovaty wrote:
>
> >You can get started, if you're willing to use the magic-removal branch. :)
> >
> >The event system is in that branch, in django.dispatch.
> >
> >
> Ok. I'll get to it as soon as I could kill some more lines from ToDo on
Adrian Holovaty wrote:
You can get started, if you're willing to use the magic-removal branch. :)
The event system is in that branch, in django.dispatch.
Ok. I'll get to it as soon as I could kill some more lines from ToDo on
my desktop :-)
On 1/11/06, Maniac <[EMAIL PROTECTED]> wrote:
> I kinda want to write such a thing if there are no serious objections
> and when event system is ready.
You can get started, if you're willing to use the magic-removal branch. :)
The event system is in that branch, in django.dispatch.
Adrian
--
A
Maniac wrote:
- auth app using event system hooks to the save event for models
- auth middleware populates request.user and also keeps the user for
itself in some warm private place
- on model's save it looks in its Meta for fields that should be
populated and does it
Wait, there's more! :-
Adrian Holovaty wrote:
I don't see a need to add this functionality for use beyond the scope
of the admin site.
Well... I can recall more than one request in django-users :-). And this
feature is pretty commonplace...
The auto_now options aren't coupled to a request,
so they're a special c
Adrian Holovaty wrote:
> On 1/11/06, Maniac <[EMAIL PROTECTED]> wrote:
>
>>This will work only in Admin but authentication generally isn't tied to
>>it. I recall that people in django-users were interested in automatic
>>user assignment to work in any view and they didn't want to insert
>>"SomeMo
On 1/11/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/11/06, Maniac <[EMAIL PROTECTED]> wrote:
> > This will work only in Admin but authentication generally isn't tied to
> > it. I recall that people in django-users were interested in automatic
> > user assignment to work in any view and
On 1/11/06, Maniac <[EMAIL PROTECTED]> wrote:
> This will work only in Admin but authentication generally isn't tied to
> it. I recall that people in django-users were interested in automatic
> user assignment to work in any view and they didn't want to insert
> "SomeModel.created_by=request.user"
On 1/11/06, Maniac <[EMAIL PROTECTED]> wrote:
>
> Joseph Kocherhans wrote:
>
> >Create a ForeignKey field that references
> >django.contrib.auth.models.User or whatever. This field cannot be
> >editable=False, or the manipulator will skip over it when you save the
> >object. Exclude the field from
Joseph Kocherhans wrote:
Create a ForeignKey field that references
django.contrib.auth.models.User or whatever. This field cannot be
editable=False, or the manipulator will skip over it when you save the
object. Exclude the field from your admin screens using the fields
attribute of the new inn
On 1/11/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > Create a ForeignKey field that references
> > django.contrib.auth.models.User or whatever. This field cannot be
> > editable=False, or the manipulator will skip over it when you
2006/1/11, Adrian Holovaty <[EMAIL PROTECTED]>:
> Oooh, I like this. Putting methods in the inner Admin class is very clean.
>
\o/
--
Brice Carpentier aka Br|ce
On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Create a ForeignKey field that references
> django.contrib.auth.models.User or whatever. This field cannot be
> editable=False, or the manipulator will skip over it when you save the
> object. Exclude the field from your admin screens usin
2006/1/11, Joseph Kocherhans <[EMAIL PROTECTED]>:
> Create a ForeignKey field that references
> django.contrib.auth.models.User or whatever. This field cannot be
> editable=False, or the manipulator will skip over it when you save the
> object. Exclude the field from your admin screens using the f
On 1/11/06, Brice Carpentier <[EMAIL PROTECTED]> wrote:
>
> 2006/1/11, Joseph Kocherhans <[EMAIL PROTECTED]>:
> > I wrote both patches. Please just ignore #1132. It sucks. I was pretty
> > much just trying to start a conversation there with the simplest (in
> > this case least amount of code) thin
2006/1/11, Joseph Kocherhans <[EMAIL PROTECTED]>:
> I wrote both patches. Please just ignore #1132. It sucks. I was pretty
> much just trying to start a conversation there with the simplest (in
> this case least amount of code) thing I could get to work. (I probably
> should have done so on the li
2006/1/11, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Hi folks,
> Yes, I'm bringing this issue again, please don't throw things at me !
>
> Basically, I would want to open a discussion on these subjects so as to
> define a clean solution to this problem, if at least possible.
>
> I think I'm gonna g
On 1/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> 1132 and 1164 both provides solutions for the CurrentUser issue), but
> as
> of now, these solutions have been (in my own opinion rightly) deemed
> too
> hackish to get committed. This thread is aimed at finding a clean
> implementation
Hi folks,
Yes, I'm bringing this issue again, please don't throw things at me !
Basically, I would want to open a discussion on these subjects so as to
define a clean solution to this problem, if at least possible.
I think I'm gonna give some use cases that should, in my very humble
opinion, be
21 matches
Mail list logo
