Isn't 'database' going to be an option in a model's Meta? In this
situation, is admin going to attempt to do something different?
-S
On Dec 4, 9:18 am, Nan wrote:
> > 1) Ignore the problem. Admin works on the default database, but
> > nowhere else. This is certainly less than ideal, but it would
Oh, I see from a later message by Alex that Meta.using was removed.
-1!
-S
On Dec 5, 3:12 pm, "subs...@gmail.com" wrote:
> Isn't 'database' going to be an option in a model's Meta? In this
> situation, is admin going to attempt to do something differen
http://dpaste.com/160722/
class Contact(models.Model):
program = models.ForeignKey('agency.Program')
consumer =
models.ForeignKey('consumer.Consumer',null=True,blank=True)
date = models.DateField('Contact Date')
notes = models.TextField()
date_added = models.DateTimeField(edita
creation.
>
> Also, people are en route to PyCon, so responses may be a bit slow.
>
> On Wed, Feb 17, 2010 at 3:30 PM, subs...@gmail.com wrote:
> >http://dpaste.com/160722/
>
> > class Contact(models.Model):
> > program = models.ForeignKey('agency.Program'
Sorry to be pushy, but I would like to bump this or find the next tree
to bark up.
-S
On Feb 17, 9:42 pm, "subs...@gmail.com" wrote:
> bmodels.Contact.objects.select_related('IR_contact','consumer_contact','program','consumer').filter(
http://code.djangoproject.com/ticket/12937
Went ahead and filed it here. I set the milestone for 1.2, I'm hoping
that triggers a review at some point.
On Feb 21, 7:16 pm, Russell Keith-Magee
wrote:
> On Mon, Feb 22, 2010 at 7:45 AM, subs...@gmail.com wrote:
> > Sorry to be push
Hello there,
I'm interested in allowing a particular filter I have to check the
context. Trolling for reasons for and against, and if it makes no
difference I'll file a ticket and provide some patches.
Its useful for me in cases where the thing I am processing has already
been processed before. T
I guess at some point its just feature-clut. Its a use case we _could_
encompass, but would you really even find yourself using it?
I don't see the technical difference here--pre-syncdb, you either have
to 'wade' to the database or you have to 'wade' to this item in
settings.py. Its not as though
I got myself into a situation with a project and some comments models.
Perhaps with some discussion we can uncover genuine code-bugs, but my
knowledge about this is limited and so I'm just calling for a
documentation update. A major reason I'm asking for some notice of
these things to appear somewh
If we could visualize the entirety of data within django-projects, we
would probably see that this 'data economy' is growing exponentially
year-over-year. However, I know of no guided way to actually get this
data into a project that's been converted to Django. There are two
methods I generally hea
to a shape where it _will_ work, rather than
resorting to scripting the entirety.
> On Thu, 2010-03-25 at 09:07 -0700, subs...@gmail.com wrote:
> > mix). With talk of model-level validation, the first approach is
> > becoming increasingly invalid,
>
> That's not a c
> > Adding system administration functionality to Django, which is what this
> > monitoring is, feels like the wrong approach.
I see here you probably meant its appropriate elsewhere but not in
django. Gotcha. Thought I'd try anyhow.
--
You received this message because you are subscribed to the
> On 25/03/10 17:47, subs...@gmail.com wrote:
>
> >> The last bit sounds a bit nebulous. You could optimise it by not
> >> including any empty files, or be a bit more specific about what the
> >> empty files are meant to represent. :)
>
> > startapp, s
Or let's circumvent the whole problem by stopping this garbage at the
gates!
On Mar 25, 11:34 pm, Richard Laager wrote:
> This might be a bit off-topic for this thread, but legacy data is why I
> wish frameworks supported some concept of warnings in their validation
> code.
>
> Richard
--
You r
> I can't think of any reason that a production server should behave
> differently to a development server on the sorts of issues you're
> referring to. If there's a problem, I would be highly surprised if
> it's caused by the fact you're running under wsgi, rather than the
> devserver. There may b
Seems like a security hole, whereby people may supply additional
fields if they can guess their counterparts on the model. Its
'exclude', not 'exclude_maybe'.
...Unless I'm missing something fundamental.
-S
On Mar 31, 9:11 pm, orokusaki wrote:
> I'm working on an SAAS project, and there is an `
Please note I've already consulted secur...@djangoproject.com about
this and Jacob told me to post it here if I wanted to.
One problem with authenticated sessions is that, upon de-activation of
a user's account, any sessions that user has remain live until they
logout.
I think it would be a good
Oh, and I apologize for the racy subject line =)
On Apr 15, 10:51 am, "subs...@gmail.com" wrote:
> Please note I've already consulted secur...@djangoproject.com about
> this and Jacob told me to post it here if I wanted to.
>
> One problem with authenticated sessions
Thanks for breaking it down.
On Mar 17, 7:45 am, Russell Keith-Magee
wrote:
> 1) Don't touch the code. It's an annoying edge case, but it can be
> caught by shortening session timeouts and making more use of
> permissions. However, we should document the edge case with
> login_required, as it i
Could the burden of this work be successfully (and sensibly) shifted
to the backend itself by calling something like... deactivate()?
In this event, the default backend's logic could be 'set is_active =
False and expire cookie' and custom backends could do (or not do)
whatever they want.
Forgive
I recently ran into this problem too for the first time. Essentially
this boils down to my not being able to use a templatetag in a loop in
some cases. What is the simple workaround that I'm missing?
-Steve
On May 5, 2:12 pm, Apreche wrote:
> I had a really strange bug in one of my custom templa
Hello there,
I'm watching #5833 and I have a bit of a problem with the
implementation. A good example of their proposal is here:
http://code.djangoproject.com/ticket/5833#comment:68
The API is remarkably similar to Gaynor's django-filters. My problem
with this is that your filtering essentially
Maybe code talks?
I added a patch to http://code.djangoproject.com/ticket/5833 which
sums up the kind of change I am gunning for. If anyone has some
feedback, awesome.
-Steve
On Sep 7, 3:22 pm, "subs...@gmail.com" wrote:
> Hello there,
>
> I'm watching #5833 and I have
I may be dense but is this the functional equiv of cobtrib.comments
get_model()?
On Sep 26, 8:28 am, Klaas van Schelven
wrote:
> Hi all,
>
> I'm looking for a bit of input for making Django's apps a bit more
> extendable, either by modifying Django or (preferably) by coming up
> with a common lan
I thought that's what get_model did?
You specify your own comments app and register your own (subclass or
other) model within that function and its used throughout the original
app.
On Sep 27, 3:02 am, Klaas van Schelven
wrote:
> On Sep 27, 4:17 am, "subs...@gmail.com" wro
Error: Cannot assign "":
> "CommentFlag.comment" must be a "Comment" instance.
>
> You see the problem? Any help thinking about the solution is much
> appreciated.
>
> Klaas
>
> On Sep 27, 7:57 pm, "subs...@gmail.com" wrote:
>
>
>
Speaking of which... who is interested in admin these days? Been
trying to scare up some feedback @ http://code.djangoproject.com/ticket/5833
for some time now.
On Sep 29, 2:39 pm, Jacob Kaplan-Moss wrote:
> sense to have more area-specific committers. If someone's well-versed
> in the admin, a l
Jacob Kaplan-Moss wrote:
> On Wed, Sep 29, 2010 at 3:21 PM, subs...@gmail.com wrote:
> > Speaking of which... who is interested in admin these days? Been
> > trying to scare up some feedback @http://code.djangoproject.com/ticket/5833
> > for some time now.
>
> Please
Hello all,
I was browsing the tickets and saw a few of them nagging about some
restrictions to raw_id_fields. That they are limited to other objects
registered in admin, that they are limited arbitrarily (relative to a
regular FK) by the permissions of the user, etc. Personally, I find
the little
n Thu, Sep 30, 2010 at 12:34 PM, subs...@gmail.com wrote:
> > Hello all,
>
> > I was browsing the tickets and saw a few of them nagging about some
> > restrictions to raw_id_fields. That they are limited to other objects
> > registered in admin, that they are limited arb
t_name']}. The list in this case is the
search_fields which kind of mirrors admin's current functionality. Or
maybe I'm getting ahead of myself.
-Steve
On Sep 30, 2:21 pm, "burc...@gmail.com" wrote:
> On Thu, Sep 30, 2010 at 10:27 PM, subs...@gmail.com wrote:
> >
And then it was so:
http://code.djangoproject.com/ticket/14370
On Sep 30, 3:54 pm, "subs...@gmail.com" wrote:
> Yeah, I think your right. raw_id_fields is a neat idea if you really
> are reluctant to use AJAX. If introducing AJAX into admin is fine,
> dumping these fields a
I know I'm not a core dev but I do have two cents.
I'm not really in favor of overthinking this too much--I think a
satisfactory replacement for raw_id_fields is good enough (adequately
encompasses all the features). I know there are a lot of mature
projects out there when it comes to AjaxFields a
Edit. Edit.
"I just don't think making an absolute answer to that discussion a
contingency to this called-for feature /is a good idea/".
There we go.
On Oct 1, 11:19 am, "subs...@gmail.com" wrote:
> Please don't think I'm trying to hinder discussion. I
Does anyone besides me think that an AJAX field admin solution
effectively deprecates raw_id_fields?
I'm interested in seeing a ticket like #14370 go forward if only to
close a slew of dusty old tickets about raw_id_fields.
-Steve
On Oct 3, 5:58 am, Marcob wrote:
> Well, M2M and raw_id_fields a
With the AJAX field implementation on the table you're free to
represent the objects however you want. Yeah, there's a few things
left out but did you really say 'no searching'?
-Steve
On Oct 3, 10:09 pm, Chuck Harmston wrote:
> it's based on the assumption that the user knows the value of the u
ete widget (which, as I said, already
> exists in the admin-ui branch), but do not want it to replace raw_id_fields;
> their uses cases are completely disparate.
>
> On Mon, Oct 4, 2010 at 12:05 AM, subs...@gmail.com wrote:
>
>
>
>
>
> > With the AJAX field implementa
Neither did I until today. It is understandable that from a use-case
perspective, inlines look less like 'Deletes' and more like
'Disassociates' (from the admin model). Janet thought so in the office
when she nuked a few years worth of survey data, and I think its a
rather blameless mistake. Neverm
Heh, already put a few hours doing something like this. There's some
django-discus attempts out there--have you looked at them? I haven't
bothered to notice if any use the comments framework but it sure would
be handy to make comments out of discus or backtype feeds or variants
thereof.
But whethe
Hello everyone,
I posted to the user's list but haven't heard anything. I am wondering
if this sounds like it could potentially be a bug:
http://groups.google.com/group/django-users/browse_thread/thread/253b77110fb68a89
if this is due to my misunderstanding of routers, please forgive my
posting
I found I had another router that was being greedy.
On Apr 8, 12:15 pm, "subs...@gmail.com" wrote:
> Hello everyone,
>
> I posted to the user's list but haven't heard anything. I am wondering
> if this sounds like it could potentially be a bug:
>
> http:
Could anyone provide a use case where I want a de-activated user to
remain authenticated? Who is this option for? Why is it default?
When I originally reported this ticket I did so because this is a
plain security risk--non-technical users uncheck 'is active' when they
want to lock someone out of
Basic demand side problem. When an app stands up and solves the real
issues (which, as the DjangoCon presentation proved, there were many)
involving App Engine and Django, then I (and the demographic of
developers I statistically represent) will become excited.
-S
On Feb 6, 9:51 am, David Stengl
43 matches
Mail list logo
