Re: formsets should be iterable: closed [WONTFIX] -- why

[KentH]

Hi Russ,

Thanks very much for applying the patch (especially finding the docs,
finding the tests, updating the docs, and updating the tests...).

I appreciate your effort & your mentoring. I'll do better with the
next patch.

Thanks again, Kent

-- 
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: Delete leads to IntegrityError (Trac Ticket #14896)

[Russell Keith-Magee]

On Mon, Dec 20, 2010 at 9:49 PM, thierry  wrote:
> Hi all,
>
> I've tested the django 1.3 alpha release, but it seems that's the
> delete cascading rule doesn't work anymore when a class contains a
> ManyToManyField pointing on a class having subclasses. Consequently,
> I've created a ticket in django trac server (#14896) to describe my
> problem. Hope this one won't be unreviewed for a long period.

Hi Thierry,

Don't worry - your ticket has been seen, we just haven't got around to it yet.

Until we ship beta 1, our focus is on adding new features. Once the
feature freeze hits, our focus will move to squashing bugs. At the top
of the bug list are the bugs reported in features introduced in 1.3.
Bugs that involve data loss (such as yours) will be an especially high
priority.

If you want to help out (and make our lives easier in the process),
the best thing you could do would be to reduce your problem into a
test case that is integrated into Django's own test suite --
essentially writing the regression test that will be part of the final
patch.

Yours,
Russ Magee %-)

-- 
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.

Delete leads to IntegrityError (Trac Ticket #14896)

[thierry]

Hi all,

I've tested the django 1.3 alpha release, but it seems that's the
delete cascading rule doesn't work anymore when a class contains a
ManyToManyField pointing on a class having subclasses. Consequently,
I've created a ticket in django trac server (#14896) to describe my
problem. Hope this one won't be unreviewed for a long period.

-- 
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: I18N locale per app resolving - documentation incorrect or bug?

[Klaas van Schelven]

Ok, I split it out:

Documentation incorrect: (incl. patch)
http://code.djangoproject.com/ticket/14910

Code incorrect: (patch w/ test)
http://code.djangoproject.com/ticket/14924

Please review,
Klaas

On Dec 19, 1:13 pm, Klaas van Schelven 
wrote:
> Hi all,
>
> To be a bit more specific:
>
> I've filedhttp://code.djangoproject.com/ticket/14910
>
> Added a test that proves the bug. Provided code that makes that test
> green. Fixed the documentation. All including patches.
>
> Could someone with sufficient authority move this forward?  trolling remark about the state of the community here to draw
> attention to this ticket>
>
> Much obliged,
> Klaas
>
> On Dec 16, 3:25 pm, Klaas van Schelven 
> wrote:
>
>
>
>
>
>
>
> > ♫ Tom ♩ tie ♭♬ tom ♪
>
> >http://code.djangoproject.com/ticket/14910
>
> > On Dec 5, 11:37 am,Klaasvan Schelven 
> > wrote:
>
> > > Replying to myself here.
>
> > > I'm quite sure the docs are wrong by now.
>
> > > Also: I think the documented behavior is not desirable. Changing
> > > translations per-view makes for hard to debug once-in-a-while bugs.
>
> > > This means the bug '2' is still a problem. I suggest either reversing
> > > the loop
>
> > > 158         for appname in settings.INSTALLED_APPS:
>
> > > or making the update of a 'merge' non-destructive.
>
> > > Agreed? Should I move forward w/ tests, documentation update etc. in a
> > > bug report?
>
> > > On Dec 5, 11:21 am,Klaasvan Schelven 
> > > wrote:
>
> > > > Hi,
>
> > > > According 
> > > > tohttp://docs.djangoproject.com/en/1.2/howto/i18n/#using-translations-i...
> > > > andhttp://docs.djangoproject.com/en/1.2/topics/i18n/deployment/#how-djan...
>
> > > > At runtime, Django looks for translations by following this algorithm:
>
> > > > * First, it looks for a locale directory in the application directory
> > > > of the view that’s being called. If it finds a translation for the
> > > > selected language, the translation will be installed.
> > > > * Next, it looks for a locale directory in the project directory. If
> > > > it finds a translation, the translation will be installed.
> > > > * Finally, it checks the Django-provided base translation in django/
> > > > conf/locale.
>
> > > > However, this has not been my experience. I also do not see anything
> > > > in the django source code or tests that responds to the above.
>
> > > > In django/utils/translation/trans_real.py I see the following:
>
> > > > def translation(language):
> > > >      [..]
>
> > > >         for appname in settings.INSTALLED_APPS:
> > > >             apppath = os.path.join(get_apppath(appname), 'locale')
>
> > > >             if os.path.isdir(apppath):
> > > >                 res = _merge(apppath)
>
> > > > _merge (and deeper down "merge") is defined as a dictionary update in
> > > > the same file.
>
> > > > I see two problems here:
> > > > 1] the documented behavior is not implemented
> > > > 2] the implemented behavior has the opposite order-of-preference for
> > > > apps as the rest of Django. (Normally, the higher up in your
> > > > INSTALLED_APPS you put an app, the more likely it's templates, etc.
> > > > will be called. Here we're using a dict update, so the lowest app has
> > > > preference)
>
> > > > Am I missing something? I've done some grepping but couldn't find any
> > > > point where the "currently called view's app" is somehow related to
> > > > the used translation.
> > > > Should I file a bug? And if so: should we fix the documentation or the
> > > > code?
>
> > > >Klaas

-- 
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: Giving Users Permissions on a Subset of Models

[James Hancock]

Wow, thanks for the heads up. Looks like this might do the trick.

Thanks,
Elder Hancock

On Mon, Dec 20, 2010 at 4:22 PM, Lukasz Balcerzak  wrote:

> Hi James,
>
> You should check out django-authority [1] - as far as I know it is
> only row-level perms application with
> "logical checks" (rules). Other apps for managing object permissions
> are listed at djangopackages.com
> ("Permissions" grid) [2].
>
> Cheers
>
> [1] https://bitbucket.org/jezdez/django-authority/
> [2] http://djangopackages.com/grids/g/perms/
>
> --
> 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.
>
>

-- 
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: Giving Users Permissions on a Subset of Models

[James Hancock]

Chuck Harmstron,
Thanks for the warm welcome and the good advice.

I saw that row-level permissions came out with 1.2, but I wasn't sure
exactly what it was so thank you for the clarification. While I try and
figure it out for my site I will move any questions about how to implement
it over to django-users. Thanks again for the references, they really help.

Since the backend is already done for managing row level permissions, what
if there was a way to manage some of the simple ones from the admin. Just
like you can create groups and users I think it would be useful to have a
tool to add row level permissions to groups.

This would be really useful for the project I am working on. If the
community feels the same way I could start preparing now so I can apply for
GSoC on this feature later this year. I know GSoC is a little down the road
but I thought if I got started working with Django earilier I would have a
greater chance of getting accepted.

Has something like this already been planned?

Thanks,
Hancock


On Sat, Dec 18, 2010 at 11:57 PM, Chuck Harmston wrote:

> Hi James,
>
> Welcome to Django!
>
> The terminology that you're looking for is either "row-level permissions"
> or "object permissions." At a simple level, it allows you to define methods
> that return a boolean indicating whether the user should be able to
> add/view/change/delete the object. Fortunately this is already built into
> Django (as of 1.2), so we're veering into django-users territory. There are
> two ways to go about it:
>
>1. contrib.admin.ModelAdmin has three methods that implement this
>functionality within contrib.admin: has_add_permission() [1],
>has_change_permission() [2], and has_delete_permission() [3]. You can 
> easily
>override these methods (which are passed the request and object) in the
>subclass, though you may want to incorporate a super() call to preserve the
>default permissions [4] behavior.
>2. You can also handle this at the authentication backend level. This
>is enabled by creating a custom backend with the 
> supports_object_permissions
>property set to True. When this is True,
>backend.get_group_permissions(), backend.has_perm(),
>and backend.get_all_permissions() are passed additional parameters (the 
> User
>object and object in question). Your custom backend should override these
>functions to provide the default behavior. This is detailed in the docs [5]
>and contrib.auth code [6].
>
> You can take this an additional level and add field-level permissions—that
> is, controlled access to specific fields on models—to contrib.admin [7].
>
> Hope this helps!
>
>  Chuck
>
>
> [1]
> http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L301
> [2]
> http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L306
> [3]
> http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L317
> [4] http://docs.djangoproject.com/en/dev/topics/auth/#permissions
> [5]
> http://docs.djangoproject.com/en/dev/topics/auth/#handling-object-permissions
> 
> [6a]
> http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py
> [6b]
> http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/models.py
> [7] https://github.com/chuckharmston/django-fieldlevel-permissions
>
> On Sat, Dec 18, 2010 at 3:05 AM, James Hancock wrote:
>
>> Django Developers,
>>
>> This is my first post on Django-dev, so I thought I would start with a
>> short introduction.
>>
>> My name is James Hancock, and I love python. Right now I live in
>> Japan, and am developing an application for managing volunteer english
>> classes throughout the country. (You can see the site at www.goeigo.org.)
>> Obviously, the development is done in Django. As I have been
>> developing the site I have really wished that Django would have one
>> feature.
>>
>> Being able to grant permission to view, update, and create objects
>> based on a subset of the models, rather than giving access to all of
>> them. I don't know if this is correct terminology, but I like to think
>> of it as adding rules to the permissions. So a teacher has permissions
>> to see students, but only on the rule that they are signed up for his
>> class. This would really help my project and I think that it would
>> help others as well.
>>
>> I have a lot of time this summer to really get into coding when I get
>> back to the States, and I was thinking about submitting the idea for a
>> Google Summer of Code project.
>>
>> My questions are.
>>
>> 1. What Experience would I need in order to tackle a feature like
>> this?
>>
>> 2. What is the general feel about the inclusion of a feature like
>> this?
>>
>> Cheers,
>> James Hancock
>>
>> @Andrew Ball
>> I 

Re: Django support added to BuiltWith!

[Andrew Ingram]

On 20 Dec 2010, at 06:40, Russell Keith-Magee wrote:
> 
> No, there aren't any completely reliable clues -- and in my opinion,
> that's a good thing.
> 
> Providing an easy way to identify a Django site serves no purpose
> other than inflating project ego. On the other hand, if I am a black
> hat hacker, and i want to take down your site, being able to easily
> identify the software running your site dramatically narrows the
> search for possible attack vectors.
> 
> As much as I enjoy the trainspotting aspect of knowing where Django is
> being used, it is information that doesn't need to be shared by
> default. If I want to share the technology that I have used in
> building my site, I can put up a colophon page, or write a case study
> on a blog, or any number of other options. I see no reason that this
> information needs to be machine readable at all, let alone machine
> readable by default.
> 
> As Jeremy has noted, the closest you will get to easily identifying a
> Django site is to look for the telltale signs of the admin site, but
> admin is not universally deployed, nor is it universally deployed at
> /admin (in fact, I routinely use a different URL for admin
> deployment). You might also get some hints out of session cookie
> naming - but again, not every site uses Django's session framework,
> and if they do, the session cookie name is configurable.
> 
> Yours,
> Russ Magee %-)

I agree, if you can tell what server-side tools are in use then someone has 
probably done something wrong somewhere.

You may be able to guess what framework is in use by spotting certain design 
patterns that are pushed particularly strongly by a framework, but as all 
frameworks gradually move towards best practices  it'll become increasingly 
difficult to tell them apart. This is definitely a good thing, I am generally 
rather pleased if I can deploy something without someone knowing what server 
side tools are in use.

- Andrew Ingram

-- 
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: Giving Users Permissions on a Subset of Models

[Lukasz Balcerzak]

Hi James,

You should check out django-authority [1] - as far as I know it is
only row-level perms application with
"logical checks" (rules). Other apps for managing object permissions
are listed at djangopackages.com
("Permissions" grid) [2].

Cheers

[1] https://bitbucket.org/jezdez/django-authority/
[2] http://djangopackages.com/grids/g/perms/

-- 
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.