DjangoBot: #django-dev

tclineks: ooh, bribes are always welcome

tclineks: which ticket are we talking about here?

#7150 and #820

james closed 7150 as dupe of 820

tclineks: ah, I see.

tclineks: http://www.djangoproject.com/documentation/data...

The admin's not designed for browsing, but luckily databrowse is.

yeah i dig databrowse

tclineks: if you really wanted this behavior there is no reason why you couldn't use subclassed version of ModelAdmin

tclineks: yeah, and I think it's pretty much out of scope for the admin... you could bring it up on django-developers if you feel strongly, but I kinda suspect you won't find much help there.

my usecase is a raw_id relationship -- to populate that field the user has to have change perms on the related model :(

honza posted recently on -dev about how delete was kind of handicapped as you currently have to have change perms to view the object detail page

updated patch: http://dpaste.com/57616/ could be cleaned up in a few ways, works on current nfa head

Ok I just posted a version of #4117 that only adds id, all other attrs will be handled under a different ticket(which already exists)

jacobkm: when you get to play with git again you can try a git remote update and merge my master (into some branch other than your master) then you can even try to cherry-pick to your master if you like my commits (what would close three tickets)

aside, on #7453, making it possible to still pass "status" until 1.0 with a DeprecationWarning would make that one ready?

jacobkm: Any opinions on the new patch I added to #4117 which essentially only adds the id to the ul and we'll defer dealing with the rest of the attrs until #3515 gets figured out?

guys, If I want to raise a DeprecationWarning should I import warnings at the top of the file or in the method that will raise the warning?

telenieko: in the method that raises the warning, prefereably inside the if: block around the warning.

ups, I took newforms as example: from warnings import warn, at the top of the file. I'll move mine to the if block. Thanks

how's your git playing going? ;)

what's the stacklevel parameter to warn() for¿

mm.. My shell doesn't show PendingDeprecationWarning's any clue?

telenieko: that's because pending warnings are silent by default. Use a DeprecationWarning.

ok, thanks

form_for_model raises a Pending one ;)

That should get promoted one of these days.

there are only two PendingDeprecationWarnings, both in newforms

Doesn't oldforms itself raise a deprecation warning?

I did a grep -n -R and only newforms appeared

git merge --squash tmp/ticket_branch && git commit < nice :)

I can't find any warnings in oldforms... rare

Actually there probably aren't since then you'd get them all over the place in the admin

yup, maybe after 1.0-beta we can start raising them, hehe.

r7488 <-- eyeballs wanted :)

?

r or # ?

ugh yeah #7488

the changeset is nice anyway "Migrated to america" xD

hehe

by upstream you mean in models instead of newforms?

correct. should the queryset i posted work when in model inheritance

Should, if non-inherited return empty lists, inherited should also. The behaviour should be consitent (if I got the problem right)

right so it should be fixed upstream

I think so.

in trunk maybe ;)

oh right. i pointed out nfa branch because it was easier ;)

the line numbers are off by a few

np. I'll change the ticket's component and version then if you don't mind ;)

i wonder if this problem has been reported though against trunk. i haven't looked

mm... let's call the friend google :)

but I don't remember a ticket about this.. mmmm

after 5 hours, git svn just finished doing a new clone of django :))))

time to remake my screwed repo!

#3016 looks similar. i think that has been fixed since qs-rf

however, it does feel right to return an empty queryset when self.instance.pk is None in BaseInlineFormset.get_queryset

time to sleep! see you tomorrow

bye¡

bye telenieko!

jezdez: do you sleep? you're always here when I say "hi" and "bye"!

:) I do

I'm on a irc bouncer

you cheat :P

yep :)

see you in 8 hours or so ;)

good night!

good night ^^

anyone think a newforms DateInput and TimeInput would be useful to go along with the existing DateTimeInput? SplitDateTimeWidget is currently a bit weird in that it uses two TextInputs and relies on the default string representation of a datetime.date and datetime.time respectively, with no way to change it

i would think so

hactually, since dates and times have .strftime, just modifying SplitDateTimeWidget to hold default date/time formats and the necessary keyword args should do the trick

i really need to get my DurationField updated with a newforms widget

er, a newforms-admin widget, rather