Re: Django and the new EU anti-cookie law

[andybak]

Here's a good summary of the issues: 
http://www.torchbox.com/blog/eu-law-cookies-and-ico

You can skip to the section titled: 'What enforcement have the ICO
announced?'

It looks like enforcement will lean towards the pragmatic.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Caching model choice fields in admin inlines.

[andybak]

I seem to recall a similar problem rears it's ugly head on editable
changelists too.

And obviously it's potentially worse there as n can often be larger.

On May 23, 4:29 pm, Sean Brant  wrote:
> If you have ever used a inline in the admin for a model that contained
> a model choice field you have probably noticed it has to query the
> database for each row to fill the select drop-down. This results in n+
> identical queries.
>
> I though it might be useful to have a way to tell a admin inline to
> cache the choices of fields. Here is some rough code that gets the job
> done::
>
>     from django.forms.models import BaseInlineFormSet
>
>     class CachedInlineFormSet(BaseInlineFormSet):
>         cached_fields = []
>
>         def _construct_form(self, i, **kwargs):
>             form = super(CachedInlineFormSet, self)._construct_form(i,
> **kwargs)
>             for cache_field in self.cached_fields:
>                 field = form.fields[cache_field]
>                 field.cache_choices = True
>                 choices = getattr(self, '_cached_%s_choices' %
> cache_field, None)
>                 if choices is None:
>                     choices = list(field.choices)
>                     setattr(self, '_cached_%s_choices' % cache_field,
> choices)
>                 field.choice_cache = choices
>             return form
>
>     class CachedTabularInline(admin.TabularInline):
>         cached_fields = []
>
>         def get_formset(self, request, obj=None, **kwargs):
>             formset = super(CachedTabularInline,
> self).get_formset(request, obj=None, **kwargs)
>             formset.cached_fields = self.cached_fields
>             return formset
>
>     class MyInline(CachedTabularInline):
>         model = MyModel
>         cache_fields = ['myfk']
>
> Im not super big on how this patches the classes in various places so
> i'm open to better suggestions. Is this something that the admin could
> benefit from or is this better kept as a 3rd party tool?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: More efficient negative lookups

[andybak]

One small related point.

The admin could benefit from a way of doing negative lookups within
the lookup syntax itself.

Currently there is no way to construct an exclude filter change list
views in the URL.

i.e. If I am writing a custom filterspec or anything else that results
in a URL for a changelist page then I can do:

/admin/app/model/?model__id__exact=4

but I can't reverse the logic.

There might be better ways to allow this than just adding a negative
version of every lookup but I thought I'd throw another use case into
the ring.

Andy

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Admin - Selector Inlines in 1.3?

[andybak]

Hi,

As far as I know this is the only major chunk of Zain's SOC work that
didn't make it into 1.2

There's a ticket for it: http://code.djangoproject.com/ticket/12509
that's at 'design decision needed'

What would be needed to get this rather nice feature into 1.3?

cheers,

Andy

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: contrib.Auth

[andybak]

I recently tried to use the recommended approach for custom user
profiles: http://docs.djangoproject.com/en/dev/topics/auth/#auth-profiles

and all the brick walls I hit were admin related. Whether these are
better fixed in contrib.auth or contrib.admin is hard to say:

1. I can show profile fields in the user changelist but I can't sort,
filter or search on them or use list_editable on them.
2. I can re-register my own ModelAdmin for users to customize the User
admin but I can't add custom filterspecs as that requires editing the
auth models.py

#1 could be mitigated if contrib.admin allowed more ways to following
relationships for things like list_display and list_filter.
#2 requires a more elegant way to write custom filterspecs without
touching models.py - maybe this is already possible?

Andy Baker

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django Design Czar

[andybak]

This is all very timely. Myself and my friend Harry Brignull (who runs
the UX blog http://www.90percentofeverything.com ) have been talking
for a while about the idea of doing some formal usability testing on
the Django admin and this might prove to be the catalyst.

I'll put together our plan and post something on this list to get some
feedback before we go ahead.

The basic plan is to test with non-technical volunteers to try and
indentify some of the areas that might not be immediately intuitive. I
plan to use a simple CRM app as the test case but I'm open to any
better suggestions. Basically a simple app that exercises most of the
interaction types in the contrib.admin

Andy


ixxy.co.uk

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Admin-Actions also in the object details view

[andybak]

I can see some benefit in consistency here but what do you do about
saving the current object?

This is a problem in general with any actions performed on the same
screen a change form.

1. User enters the object detail view
2. User changes a field
3. User selects an action.

Does the action apply to the saved or unsaved state? If the former
then the admin must warn that the object will be saved before
performing the action whereas the latter option would be rather
confusing (do we keep or drop the changes?)

In general I don't think performing actions on an object makes sense
in 'edit' mode and there is no details view in the Django admin other
than an 'edit' mode.

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Non-trivial question: New subclass companion for Stacked/Tabular Inlines

[andybak]

I'm pretty sure Zain has made all the inline types sortable on his
admin-ui branch.

On Nov 8, 7:58 am, Tim  wrote:
> I very much like the look of that one, but I'm not sure if it
> completely fills the need I want for my own project.  All of the
> fields need to be quickly visible, without needing to know the
> rendered name of the instance.
>
> Those 'new inlines' address the problem of space, but they cater to
> those who already know what they're looking for.  My coworkers need to
> constantly look over lists of location addresses, and require that all
> the fields are displayed for quick scanning.  In other words, the
> users of this particular admin page will rely very heavily on it to
> show them all the data at all times.
>
> Another improvement to inlines in general would be to make them
> sortable.  There are some Javascript enhancements out there for
> sorting HTML tables by any column, by clicking on its  tag.  The
> 'new inlines' don't really allow for this possibility.
>
> (I did make a simple app out of the 
> TiledInline:http://code.google.com/p/django-tiledinline/)
>
> Again, thanks for the feedback!  I should play more with those new
> inlines.  I really do think that there is potential there, as with
> most of the wonderful things that come from GSoC.
>
> Tim
>
> On Nov 7, 5:23 am, Renato Garcia Pedigoni 
> wrote:
>
> > Hi Tim
>
> > Wouldn't be the 'new inlines'  [1] of GSoC admin improvements a nice
> > approach? The height is fixed, no waste of space... And no need to have
> > blank fieldsets for new objects (the 'extra' inline option).
>
> > But anyway sometimes Stacked and Tabular just don't fit, it's nice to have
> > another way to show related objects.
>
> > [1]http://media.wilsonminer.com/images/django/related-objects-stacked.gif
>
> > Renato
>
> > On Fri, Nov 6, 2009 at 11:59 PM, Tim  wrote:
>
> > > On Nov 6, 6:20 pm, Alex Gaynor  wrote:
> > > > This sounds interesting, but I'm having a hard time visualizing it,
> > > > any chance you could provide some screenshots?
>
> > > Absolutely.  I wrote up a blog post about it today:
> > >http://mangos.dontexist.net/blog/?p=352
>
> > > There are a couple of screenshots listed there.
>
> > > I truly find this most useful when dealing with TextFields, like I
> > > mention in the blog post, because if you get 5 or 6 of those together,
> > > they get really wide really fast, and neither the Stacked nor Tabular
> > > really suits the situation, in terms of usability.
>
> > > > As for whether it
> > > > should be included I'd say the first step is to get it out there in an
> > > > app anyone can download, as things like this can live outside of
> > > > Django.
>
> > > Yeah, with the blog post there is a zip file download.  It's not
> > > really in an "app" form, but that can be done fairly easily.  I shall
> > > put one together, for the sake of getting it working as close to zero-
> > > config as possible.
>
> > > Thanks much for the reply.  Glad to hear some interest.
>
> > > Tim
>
> > > > Second, if you are serious about getting this included in
> > > > Django I'd file a bug and upload a patch, it's much easier to discuss
> > > > these things when there's something concrete on the table.
>
> > > > Alex
>
> > > > --
> > > > "I disapprove of what you say, but I will defend to the death your
> > > > right to say it." -- Voltaire
> > > > "The people's good is the highest law." -- Cicero
> > > > "Code can always be simpler than you think, but never as simple as you
> > > > want" -- Me
>
> > --
> > Atenciosamente,
> > Renato Garcia Pedigoni
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Tutorial Refresh

[andybak]

Another thing that might be useful to cover in the tutorial is the
'building for re-usability' ideas that have devloped via Pinax et al.

Maybe at least one part of the functionality developed in the tutorial
should be in the form an app intended to be used across projects.
Combine this with incorporating existing 3rd party apps in the project
and we've captured a very powerful lesson about Django.

(edit - this is already hinted at in some of the other comments but
I'll still post this for the extra emphasis)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: proposal: decouple admin index page from INSTALLED_APPS

[andybak]

I've been hoping a discussion like this would start as soon as 1.1 was
out the door. It would tie in nicely with the Admin GSOC work as well.

I would like to chime in with some ideas for requirements and stay
away from the implementation discussion for now.

1. I think worrying about projects vs. apps is a red-herring. We are
talking about a way to configure an admin app. There might be several
of these on a 'site/project/whatever'

2. Some ability to regroup and choose better names is a biggie. It
pains me when I try and explain to my admins what 'auth' means...

3. A way to have custom entries in an category that don't relate to a
model and don't neccesarily have add and change links. This would
allow us to integrate projects like Django-filebrowser into the admin
nicely without the code copy and pasting that comes from the admin
template override mechanism.

5. Talking of the admin template override mechanism for those times we
are forced to use it can we have lots lots more blocks? Object-tools,
I'm looking at you!

6. (pony time) When everyone comes to their senses and accepts that
jQuery is going to be an essential ingredient in contrib.admin, then
jQuery.ui tabs add a whole heap of awesome to the admin index page :-P

cheers!

Andy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: JS library in admin and tools

[andybak]

That's because the backed the wrong framework.



On Aug 19, 9:05 am, Andreas  wrote:
> By the way, rails is going agnostic in 3.0... Says it all.
>
> On Aug 18, 4:06 pm, diogobaeder  wrote:
>
> > Hi there,
>
> > After reading this 
> > posthttp://groups.google.com/group/django-developers/browse_thread/thread...
> > I decided to ask you guys about your opinions in choosing an official
> > JavaScript library for Django - what would be the benefits and
> > drawbacks of that -.
>
> > I mean, Rails has an official JS library (Prototype/script.aculo.us),
> > Symfony too (Prototype/script.aculo.us), and both can work with other
> > libraries without too much rework.
>
> > Well, as an Prototype ex-user, and as a currently jQuery heavy user, I
> > much recommend jQuery, because of its ease of use and unobstrusive
> > approach - it doesn't clash with other libraries or classes -.
>
> > Also, as Django Developer Tools already uses jQuery, it would be great
> > to adopt the same library for it and the admin site, if this extension
> > gets to the Django trunk.
>
> > Diogo
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Allowing single values instead of tuples for choices in ChoiceField

[andybak]

It does get slightly uglier when you have cases such as:
f = CharField(choices=zip
(some_complex_expression_that_generates_a_list,
some_complex_expression_that_generates_a_list))

You don't really want to assign the expression to a variable within
your model and if you put it elsewhere then it hurts readability
somewhat.

I doubt that this is sufficient to sway anyone but I thought I'd throw
in my +0.5 ;-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Try out new inline features [GSoC admin-ui]

[andybak]

Nice!

Are you planning to do anything to finesse the behaviour of the
'delete' button? It would be nice (especially on selector inlines) if
it looked like items disappeared immediately.

I also feel the admin change pages needs a 'cancel' button. It's quite
counter-intuitive that the way to leave the page without saving
changes is to simply navigate away without clicking save. This has
come up in a couple of quick usability tests. (Incidentally - is
anyone else doing usability tests on the Django Admin? It would be
nice to pool findings)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Focusing on inlines this week

[andybak]

Looking good. I'm so looking forward to this. I'll be able to dump a
fair bit of my less attractive code when this gets merged.

As you are knee deep in the code for inlines - how feasible is it ever
going to be to have inlines within inlines? I can imagine the UI
issues along would be thorny but I'd be interested to know whether a
lot of refactoring would be neccesary.

And while you are tampering with the templates - can we have lots of
juicy blocks to override? The current templates are a little bit
stingy in that regard!

cheers,

Andy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

autodiscover for contrib.sitemaps

[andybak]

I have recently been working on an app that was similar enough in
functionality to contrib.sitemaps for me to use that code as a base.

It struck me that the way you register apps with sitemaps was a little
clunky and could use a bit more DRY .

Is there any reason it couldn't adopt the same approach as
admin.autodiscover?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Template block for submit buttons in admin's change_form.html

[andybak]

I remember seeing a couple of places where some extra template blocks
could help with extending the admin (object-tools springs to mind).
What are the pro's and con's of adding a sprinkling of new blocks?

On Oct 25, 5:14 pm, suuntala <[EMAIL PROTECTED]> wrote:
> G'day all,
>
> After a quick search, it seems I am not the only one who has had
> problems changing the submit buttons on an item's change view in the
> admin application. Some people even use JavaScript for this. For me
> the problem is that I would just like to change the buttons but still
> use admin/change_form.html as the base for my template without having
> to rewrite the whole "content" block.
>
> So, my question is: would it be possible to put the submit buttons
> inside their own block? Maybe there aren't too many cases where this
> would be useful but I can't see how it could do any harm either. Or am
> I missing something here?
>
> Now admin/change_form.html has this:
>
> {% submit_row %}
>
> What if that would be changed to, for example:
>
> {% block submit_buttons %}{% submit_row %}{% endblock %}
>
> Mikko
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---

Re: Proposal: Minor admin CSS refactoring

[andybak]

Good news.

I'm sure there are tickets for this but I see a lot of breakages when
grouping fields into fieldsets. Labels in particular tend to be oddly
spaced and SELECT's often wrap to a different line to their label.


On Oct 16, 9:35 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 16, 2008 at 3:28 PM, Wilson <[EMAIL PROTECTED]> wrote:
> > Goals:
>
> > 1. Make the admin CSS files easier for multiple editors and more
> > version-control friendly
> > 2. Reduce unnecessary complexity of the admin CSS file structure
> > 3. Replace obscure CSS parser hacks currently used to filter CSS for
> > IE
> > 4. Encourage reuse of existing admin styles in custom app admins
>
> This all sounds good to me...particularly the part about removing the
> null.css file!
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | everyblock.com | djangoproject.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---

Re: Displaying current file in admin for a filefield

[andybak]

Apologies. Meant to post that to Django-Users (although I've probably
got a better chance of a useful answer here I am aware that it's not
really the right question for this group).

However now it's here - any tips gratefully received!

On Oct 2, 2:22 pm, andybak <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> I'm looking to figure out how to subclass the widget for the FileField
> in newforms-admin so that it displays the current filename next to the
> upload field.
>
> Does anyone know there are any examples/resources to help me get
> started? I assume I need to subclass forms.widgets.Widget and override
> the render method at the very least.
>
> thanks in advance,
>
> Andy


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---

Displaying current file in admin for a filefield

[andybak]

Hi there,

I'm looking to figure out how to subclass the widget for the FileField
in newforms-admin so that it displays the current filename next to the
upload field.

Does anyone know there are any examples/resources to help me get
started? I assume I need to subclass forms.widgets.Widget and override
the render method at the very least.

thanks in advance,

Andy


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---

newforms-admin still broken?

[andybak]

Hi,

As far as I can tell newforms-admin has been broken for the last week.
Add and change pages are broken for most objects (I think any with a
foreign key) and the error given is something like:
TypeError at /admin/cms/keyword/add/
instancemethod expected at least 2 arguments, got 0

It appears that 5505 is at least good enough as a temporary patch but
this patch is itself now broken against the current newforms-admin in
SVN. It's fairly easy to modify the patch but anyone using newforms-
admin needs to:
a) really that the rather cryptically named 5505 relates to the
breakage in admin
b) work out how to fix the patch.

If it's going to be a while before this gets fixed is would it be
worth renaming 5505 so it is easier for people to find and maybe
update the patch so that it can be applied directly to the latest SVN
version?

regards,

Andy


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---

Re: newforms-admin rev 6373 perhaps self-refrencing many2many broken? deepcopy ?

[andybak]

It sounds related to this:
http://groups.google.com/group/django-developers/tree/browse_frm/thread/76e8b700b30b85ff/44359701d3b9be4c?rnum=1&_done=%2Fgroup%2Fdjango-developers%2Fbrowse_frm%2Fthread%2F76e8b700b30b85ff%3F#doc_5d6b304972a7cd5b

I think Joseph is looking into it. The current SVN version of newform-
admin is broken in several places as a result of this bug.

On Sep 18, 12:51 pm, kan <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I seem to have a problem with the newforms-admin revision 6373. When I
> have a recursive many2many it fails. The top of the call stack start
> at self.base_fields.copy() . For the simple example below when I click
> on the add keyword in the admin interface. I get the following stack.
>
> I also get the same error when I have related inline fields. I am new
> to this. Perhaps I am intruding on the developers-group. I think I
> really should raise something like a ticket. However I am posting here
> until I figure the ticket system out.
>
> Example:
>
> from django.db import models
> from django.contrib import admin
> from django import newforms as forms
>
> class Keyword(models.Model):
> """A tag on an item."""
> keyword =
> models.CharField(max_length=KEYWORD_MAX_LENGTH,unique=True)
> description = models.TextField(blank=True,null=True)
> thesarus=
> models.ManyToManyField('Keyword',blank=True,null=True)
>
> def __str__(self):
> return self.keyword
>
> class Admin:
> pass
>
> class KeywordOptions(admin.ModelAdmin):
> list_display = ('keyword','description')
>
> 
> TypeError at /admin/cms/keyword/add/
> instancemethod expected at least 2 arguments, got 0
> Request Method: GET
> Request URL:http://localhost:8000/admin/cms/keyword/add/
> Exception Type: TypeError
> Exception Value:instancemethod expected at least 2 arguments, got 0
> Exception Location: C:\Python25\lib\copy_reg.py in __newobj__, line
> 92
> Python Executable:  c:\python25\python.exe
> Python Version: 2.5.1
>
> ---
> Traceback (most recent call last):
> File "c:\python25\Lib\site-packages\django\core\handlers\base.py" in
> _real_get_response
>   81. response = callback(request, *callback_args, **callback_kwargs)
> File "c:\python25\Lib\site-packages\django\contrib\admin\sites.py" in
> root
>   136. return self.model_page(request, *url.split('/', 2))
> File "c:\python25\Lib\site-packages\django\contrib\admin\sites.py" in
> model_page
>   153. return admin_obj(request, rest_of_url)
> File "c:\python25\Lib\site-packages\django\contrib\admin\options.py"
> in __call__
>   245. return self.add_view(request)
> File "c:\python25\Lib\site-packages\django\contrib\admin\options.py"
> in add_view
>   474. form = ModelForm(initial=request.GET)
> File "c:\python25\lib\site-packages\django\newforms\forms.py" in
> __init__
>   84. self.fields = self.base_fields.copy()
> File "c:\python25\lib\site-packages\django\newforms\forms.py" in copy
>   36. return SortedDictFromList([(k, copy.deepcopy(v)) for k, v in
> self.items()])
> File "c:\python25\lib\copy.py" in deepcopy
>   173. y = copier(memo)
> File "c:\python25\Lib\site-packages\django\newforms\fields.py" in
> __deepcopy__
>   107. result.widget = copy.deepcopy(self.widget, memo)
> File "c:\python25\lib\copy.py" in deepcopy
>   189. y = _reconstruct(x, rv, 1, memo)
> File "c:\python25\lib\copy.py" in _reconstruct
>   337. state = deepcopy(state, memo)
> File "c:\python25\lib\copy.py" in deepcopy
>   162. y = copier(x, memo)
> File "c:\python25\lib\copy.py" in _deepcopy_dict
>   254. y[deepcopy(key, memo)] = deepcopy(value, memo)
> File "c:\python25\lib\copy.py" in deepcopy
>   189. y = _reconstruct(x, rv, 1, memo)
> File "c:\python25\lib\copy.py" in _reconstruct
>   337. state = deepcopy(state, memo)
> File "c:\python25\lib\copy.py" in deepcopy
>   162. y = copier(x, memo)
> File "c:\python25\lib\copy.py" in _deepcopy_dict
>   254. y[deepcopy(key, memo)] = deepcopy(value, memo)
> File "c:\python25\lib\copy.py" in deepcopy
>   189. y = _reconstruct(x, rv, 1, memo)
> File "c:\python25\lib\copy.py" in _reconstruct
>   322. y = callable(*args)
> File "C:\Python25\lib\copy_reg.py" in __newobj__
>   92. return cls.__new__(cls, *args)
>
>   TypeError at /admin/cms/keyword/add/
>   instancemethod expected at least 2 arguments, got 0


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---

Re: copy.deepcopy for newforms' Bug ?

[andybak]

>From my experience and a post on Django-users I think this has also
broken the newforms-admin change and add pages.

On Sep 15, 9:46 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sat, 2007-09-15 at 16:17 +0800, 张沈鹏(电子科大08年本科应届) wrote:
> > I tried to open a ticket , but the Trac detected an internal error
> > when I try to append the attachment .
>
> Trac doesn't like binary uploads (like zip files).
>
> Still, thanks for putting together such a small example. I'll be able to
> do something with this.
>
> Regards,
> Malcolm
>
> --
> Success always occurs in private and failure in full 
> view.http://www.pointy-stick.com/blog/


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---

Re: per object permissions in admin using newforms-admin

[andybak]

I think that must be Yuri's own work actually. Yuri?

On Sep 12, 1:42 pm, RKnobelspies <[EMAIL PROTECTED]> wrote:
> You might also want to check out this snippet:
>
> RowLevelPermissionsAdminhttp://www.djangosnippets.org/snippets/414/


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---

Re: per object permissions in admin using newforms-admin

[andybak]

Off list Yuri pointed me to a patch that by the look of it does
exactly what I need:

http://code.djangoproject.com/ticket/3987

Thanks Yuri!

On 11 Sep, 16:02, "Yuri Baburov" <[EMAIL PROTECTED]> wrote:
> 2007/9/11, andybak <[EMAIL PROTECTED]>:
>
> > Am I right in thinking that the current recommended approach to
> > restricting admin access to certain objects (or rows) on a user by
> > user basis is to use the admin hooks in newforms-admin? I've started
> > using the querysethookto remove items from the changelist page.
>
> I have it done with querysethook.
> I also have done workflow (with object statuses) and row-level
> permissions for objects withnewforms-admin.
> ...> I want users (who are linked to organisations) to only have rights to
> > change their own items. Items are linked to organisation by a foreign
> > key and thus are shown as a select list in admin.
>
> > I really want this select box to be replaced by a hidden field as the
> > choice is predetermined by the logged in user but at the very least
> > the foreign key lookup used to populate the select list needs ahook
> > if I am to restrict users from changing items to a different
> > organisation.
>
> Remove this field from a form or replace widget to one rendering nothing.
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: [EMAIL PROTECTED]


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---

per object permissions in admin using newforms-admin

[andybak]

Am I right in thinking that the current recommended approach to
restricting admin access to certain objects (or rows) on a user by
user basis is to use the admin hooks in newforms-admin? I've started
using the queryset hook to remove items from the changelist page.

However I am wondering how the following is supposed to be handled by
this approach and whether new hooks would be needed if ugly hacks are
to be avoided.

I want users (who are linked to organisations) to only have rights to
change their own items. Items are linked to organisation by a foreign
key and thus are shown as a select list in admin.

I really want this select box to be replaced by a hidden field as the
choice is predetermined by the logged in user but at the very least
the foreign key lookup used to populate the select list needs a hook
if I am to restrict users from changing items to a different
organisation.

How does the per-object permissions branch handle situations such as
this?

I am currently planning a combination of a template override with some
custom javascript to swap the select box for a hidden form field. If
security was an issue then I could also add some code via the save
object hooks.

Apologies if this is more django-users than django-dev but newforms-
admin is a bit bleeding edge and I got no response at all on the users
list. With the sprint coming up I wondered if this was worth a
ticket.That is assuming I haven't just missed an blindingly obvious
elegant way round this problem!


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---

'Add user' behaviour in newforms-admin

[andybak]

Hopefully this is a suitable post for dev as I'm trying to work out if
it's a bug worth filing or not. Apologies if it turns out to be user
error...

I'm switching between trunk and newforms-admin using a .pth file.

In trunk when I login as superuser and 'add user' through admin I
taken to "/admin/auth/user/add/" which is the page with the text
"First, enter a username and password. Then, you'll be able to edit
more user options." which afterwards takes me to the edit user screen.

However in newforms-admin takes me to "/admin/auth/user/add/"  but it
looks identical to the edit user screen (all user fields are presented
rather than just username/password)

The problem is that you can't enter a plaintext password here and have
to user the '[algo]$[salt]$[hexdigest]' syntax.

(Incidentally on #django I was told that you should be able to enter
plaintext passwords on the edit user screen but it doesn't work for
me. Anyone else?).


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~--~~~~--~~--~--~---