Re: authentication data
The generic auth branch should allow you to create your own custom permission checking system easily. Chris --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Development freeze on django.db.models
On 7/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > To all Django committers -- > > Please don't change any code within django.db.models over the next few > days. Stimulated by ticket #2306, I took a look in there (particularly > the file query.py) and was a bit taken aback by how monstrous the code > has gotten. I'll be refactoring it over the next couple of days as I > get time... Hi Adrian, Is this moratorium still in effect? Ticket #2684 has patch that touches db.models.base and db.models.options. It's not a particularly critical fix, so it can wait if necessary. However, given that the lockout is two months old, I thought I'd check just to make sure I didn't miss a memo somewhere along the line. Russ %-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Custom default managers interfere with delete operations
On 9/10/06, Ned Batchelder <[EMAIL PROTECTED]> wrote: > No filtering allowed. Hrm. I think you might be right. Taking a closer look, it seems that the deletion algorithm is fairly conservative; I can't see a way of constructing a non-default related manager that would exclude an object from deletion without breaking referential integrity. Lodge an ticket; try your hand at a patch if you're feeling adventurous. 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-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 -~--~~~~--~~--~--~---
Re: Custom default managers interfere with delete operations
Done: http://code.djangoproject.com/ticket/2698 --Ned. Russell Keith-Magee wrote: On 9/10/06, Ned Batchelder <[EMAIL PROTECTED]> wrote: No filtering allowed. Hrm. I think you might be right. Taking a closer look, it seems that the deletion algorithm is fairly conservative; I can't see a way of constructing a non-default related manager that would exclude an object from deletion without breaking referential integrity. Lodge an ticket; try your hand at a patch if you're feeling adventurous. -- Ned Batchelder, http://nedbatchelder.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 -~--~~~~--~~--~--~---
Re: authentication data
patrickk wrote: > 2. when using a custom manipulator for letting the user change his > personal values (first name, last name, address, zip_code ...), I > have to change 2 different tables (user and userprofile). that doesn > ´t seem to be clean ... ??? Can you not put first name, last name, and email in your own user_profile table and use those fields instead of the default Django fields? Leave the Django fields blank and always work with your own fields? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: authentication data
sure I could do that. not DRY though. anyway, thanks for the hint. patrick Am 11.09.2006 um 17:21 schrieb Rob Hudson: > > patrickk wrote: >> 2. when using a custom manipulator for letting the user change his >> personal values (first name, last name, address, zip_code ...), I >> have to change 2 different tables (user and userprofile). that doesn >> ´t seem to be clean ... ??? > > Can you not put first name, last name, and email in your own > user_profile table and use those fields instead of the default Django > fields? Leave the Django fields blank and always work with your own > fields? > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: manytomany and multiple selects
Hi Russ Thanks for your reply I picked option 1 which worked perfectly :-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: authentication data
Chris Long wrote: > The generic auth branch should allow you to create your own custom > permission checking system easily. Well, I'm fine with the system that's already there (or the system that generic auth will be replacing it with). Are you guys also planning on removing the admin application's dependence on contrib.auth.models.User? There are a couple other places in django where contrib.auth.models.User is used directly also. For example, see my previous "multiple authentication and session keys" thread [1]. [1] http://groups.google.com/group/django-developers/browse_thread/thread/851a3f06c5949cb0/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
CharFields and children defaulting to emtpy string
using the example model: class Name(models.Model): name = models.CharField(maxlength=100) when making a new Name object... >>> a=Name() >>> a.save() >>> a >>> a.name '' The name field does not have blank=True or null=True set, but yet I am able to create a new Name object using no parameters (because CharFields and children are defaluting to empty string). Is this the intended behavior? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: authentication data
On 9/11/06, Gary Wilson <[EMAIL PROTECTED]> wrote: > > Are you guys also planning on > removing the admin application's dependence on > contrib.auth.models.User? That's my long-term goal, but generic-auth isn't enough to get there. is_staff, is_superuser, is_active, get_and_create_messages, and probably other things need to be changed for that to happen. generic_auth just takes care of user.has_perm. That said, I don't see all of this happening for at least a couple of months. Getting the per-object-permissions and generic-auth branch merged together, then merged to the trunk will come first, and I expect that will take at least a month. Joseph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: CharFields and children defaulting to emtpy string
Gary Wilson wrote: > using the example model: > > class Name(models.Model): > name = models.CharField(maxlength=100) > > when making a new Name object... a=Name() a.save() a > a.name > '' > > The name field does not have blank=True or null=True set, but yet I am > able to create a new Name object using no parameters (because > CharFields and children are defaluting to empty string). Is this the > intended behavior? > hi, yes, (unfortunately) it is. the models do not validate their input. you will have to use a manipulator (Name.AddManipulator) to validate your input (and then save the object). making the models validation-aware is planned, but not done yet. gabor --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: SOC Integration Plan/Policy/Timeline
Any progress on this? We should make a timeline. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: SOC Integration Plan/Policy/Timeline
On 9/11/06, Joe <[EMAIL PROTECTED]> wrote: > Any progress on this? We should make a timeline. Well, it's hard to have a timeline for this sort of thing. What we need right now is *not* developer time, what we need is *user* time. In other words, we need people to: 1. Check out the SoC branches and try them out. 2. Report bugs and incompatibilities that they find. The core devs simply don't have the time to do full QA and testing of all those branches, so what we need are motivated people who want these features and are willing to help test and clean up the code. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Why request.user is a class attribute
I've just found out that request.user is an attribute of request's class not of an instance. Which means that in the environment with multiple requests (threaded or not) every request.user always points to a single LazyUser instance which is obviously a bad thing. What was the reason for this decision? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Why request.user is a class attribute
On 9/11/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > I've just found out that request.user is an attribute of request's class > not of an instance. Which means that in the environment with multiple > requests (threaded or not) every request.user always points to a single > LazyUser instance which is obviously a bad thing. What was the reason > for this decision? It may look like a class attribute, but it's not. LazyUser has overridden __get__, so request.user is a descriptor, not a plain old attibute. It *must* be assigned to the class, and not an instance, or __get__ will not be called. You can google python descriptors for more info. Joseph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Setting Content-type after contructor does not have desired affect
When creating a HttpResponse the headers are mutatable by treating the object as a dictionary. However, setting the 'Content-type' after creation does not override the constructors default mimetype. Is this as designed or a bug? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: Why request.user is a class attribute
On 9/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > On 9/11/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > > > I've just found out that request.user is an attribute of request's class > > not of an instance. Which means that in the environment with multiple > > requests (threaded or not) every request.user always points to a single > > LazyUser instance which is obviously a bad thing. What was the reason > > for this decision? > > It may look like a class attribute, but it's not. LazyUser has > overridden __get__, so request.user is a descriptor, not a plain old > attibute. It *must* be assigned to the class, and not an instance, or > __get__ will not be called. You can google python descriptors for more > info. Hmm... looking into this more, Ivan was right... kind of (and maybe this is what he meant, but it's not how I read it, sorry if I misunderstood). I did a simplified descriptor test and found that the current code *does* act more or less like a class attribute. I've created a new ticket with a patch that fixes the problem. The cached user is currently stored as an attribute of LazyUser, but should be stored as an attribute of the request. http://code.djangoproject.org/ticket/2702 Joseph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: SOC Integration Plan/Policy/Timeline
I've did some quick check of the full-text search. It needs to be polished (a simple syntax error in lucene indexer) and all backends finished or droped. I couldn't do more tests as compiling lucene needs some ricer thinking (on a amd64 linux/gentoo). I'll try to do more real test when I get some time. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Why request.user is a class attribute
Joseph Kocherhans wrote: > Hmm... looking into this more, Ivan was right... kind of (and maybe > this is what he meant, but it's not how I read it, sorry if I > misunderstood). Or it's rather me being a bit sloppy explaining... I saw the __get__ thing but I know how it works only theoretically. My complaint was based on a real bug where all my concurrent requests suddenly had a single shared user instance. > I did a simplified descriptor test and found that the > current code *does* act more or less like a class attribute. I've > created a new ticket with a patch that fixes the problem. The cached > user is currently stored as an attribute of LazyUser, but should be > stored as an attribute of the request. Thanks! This both fixes it and makes a perfect example how descriptors work :-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Are non-critical patches getting enough attention?
I greatly appreciate the hard work of the current committers, but I am starting to wonder if there are too few of them to handle the number of tickets being entered into Trac. Closed tickets with resolution of fixed: 1382 (invalid, wontfix, duplicate or worksforme: 699) Open tickets: 501 Open tickets with Adrian as the owner: 419 I don't want to come across as a whiner, I just feel that this is a question that should be asked routinely as a project grows. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Are non-critical patches getting enough attention?
On Mon, 2006-09-11 at 17:23 -0700, SmileyChris wrote: > I greatly appreciate the hard work of the current committers, but I am > starting to wonder if there are too few of them to handle the number of > tickets being entered into Trac. > > Closed tickets with resolution of fixed: 1382 (invalid, wontfix, > duplicate or worksforme: 699) > Open tickets: 501 > Open tickets with Adrian as the owner: 419 Raw statistics like this can be misleading and I think they are in this case. Yes, it's slightly disappointing to see the number creep up from month to month, but it's not a tragedy. Django still works, it's still usable in serious applications. We're getting an expanded user base and so more reports from the fringe cases are coming in (for example). We're getting more feature requests now than 10 months ago, for example. Since about half the tickets filed that have been closed are not actually requiring fixes, it's not crazy to think that the average carries across in part to the the currently open tickets as well. Probably not precisely, since many obviously bad tickets can be closed as invalid or wontfix pretty quickly, but there will be some currently open tickets that are ultimately going to be "wontfix"-ed or marked as invalid or closed en masse as part of some fix. Secondly, "open" covers a lot of items: actual bugs, feature requests (of which there are a very large number), tickets that are basically different reports of the same problem -- but in slightly different ways. If we see obvious duplicates, they are marked as such, but sometimes the dupe is not obvious, or both tickets contain very useful information or different approaches and so they are temporarily left open. I'm personally pretty guilty of leaving a few tickets open that aren't even assigned to me because I know they'll all be fixed as part of some ongoing work I'm doing (this email and some time I now have will prompt me to fix that; thanks). Others (Russel, Adrian, Jacob, Luke, James, ...) might operate the same way. Thirdly, the "Adrian as owner" measure is really bogus. The bulk of components have Adrian as the owner. I've mentioned in the past that I wouldn't mind if we had a generic user as the default owner to avoid that misperception, but it's hardly a real problem once you're aware of it. Look for tickets were Adrian has accepted the assignment (the ones with (*) next to them in reports) -- that is a better measure. If I'm doing a run through the tickets looking for low hanging fruit or items of itnerest or antiquity, I tend to ignore whoever has their name next to it unless it has (a) been accepted, or (b) changed recently, indicating that somebody has shown recent interest. Unsurprisingly, I haven't yet had anybody get annoyed that I fixed a bug they were really dying to work on. Everybody is obviously pragmatic about preferring fixes over glory. My intuition is that right at the moment we are falling behind slightly because a few of us have been distracted with other things (you know, paying jobs, etc). However, we had a few good months prior to that and I think you'll see things swing up again over the next little while (law of averages, mostly). There has been a noticable uptick in various people trying to triage bugs, which helps -- detecting obvious dupes, closing some things as wontfix or invalid based on experience and knowledge of history. I should pull out some of the GNOME and Fedora bug triaging guidelines and tailor them to Django's work practices so that more people can start helping out there. A "bug squad" of triagers never hurts. Finally, a particularly important consideration is "what is the alternative to what we are doing currently?" I have worked on a bunch of Open Source projects with much larger numbers of open tickets than Django (although they were also broader in scope) and the same questions come up there. My own personal experience is that I still can't always read Adrian and Jacobs' minds about how they want to do things. Sometimes it's because good people choose different approaches, sometimes it's because I'm completely insane, sometimes it's because I don't agree with their approach (but can still live with whatever the resolution is). Now imagine there are another two dozen people with similar good intentions and no telepathy. The pressure ratchets up on the maintainers. Arbitrarily increasing committers isn't a silver bullet, even if extremely well intentioned. Increasing, for want of a better word, second level support -- the group who help skim off the low-hanging fruit and turn real reports into patches, etc -- is not a bad aim, though. I don't think you're question is out of line, but my experience says that things aren't as bad as they may seem if you only look at the Django universe. That doesn't excuse us from continuing to work hard, but it's not panic stations by any means. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message becaus
Re: Are non-critical patches getting enough attention?
Malcolm Tredinnick wrote: > Raw statistics like this can be misleading and I think they are in this > case. Yes, it's slightly disappointing to see the number creep up from > month to month, but it's not a tragedy. Django still works, it's still > usable in serious applications. I agree it's still usable and working (and that my statistics can be taken quite out of context), my focus was on the littler patches which often aren't breaking anything. I think that part of the problem is that Trac does little to determine the eligibility of some of these patches (without requiring "telepathy" from committers). > Since about half the tickets filed that have been closed are not > actually requiring fixes, it's not crazy to think that the average > carries across in part to the the currently open tickets as well. Slight correction, 1/3 of closed tickets are marked invalid, wontfix, duplicate or worksforme. And like you say, I'm not sure you can carry that average across still opened tickets. > Thirdly, the "Adrian as owner" measure is really bogus. The bulk of > components have Adrian as the owner. I've mentioned in the past that I > wouldn't mind if we had a generic user as the default owner to avoid > that misperception, but it's hardly a real problem once you're aware of > it. I admit this was a bit cheeky to put in. What I was trying to get at by this number is that these are roughly the number of unassigned tickets - quite a large number. > I should pull out some of the GNOME and Fedora bug > triaging guidelines and tailor them to Django's work practices so that > more people can start helping out there. A "bug squad" of triagers never > hurts. That sounds like a great idea. Thanks for the reply, Malcom. I'm interested in what other people have to say on the issue, especially any ideas of any way to streamline the Django "defect/enhancement -> commit" process. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Are non-critical patches getting enough attention?
Other open source projects seem to have success with Bug Days. Anyone have experiences with bug days? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
RowLevelPermissions and OneToOne problem
I decided to try out the RowLevelPermissions branch today, and apply it to some code I haven't put into production yet. My model is essentially this: class UserProfile(models.Model): home_address = models.TextField(blank=True,null=True) user = models.OneToOneField(User) class Admin: grant_change_row_level_perm=True class Meta: row_level_permissions = True Because I'm using a OneToOneField, there's no 'id' field, instead, 'user_id' becomes the primary key. Because of this, the 'grant_change_row_level_perm' breaks the Admin. When I go to create a new UserProfile instance in the Admin, I get this: AttributeError at /admin/members/userprofile/add/ 'UserProfile' object has no attribute 'id' ... Exception Location: /Users/jayparlar/Library/Python2.4/site-packages/django/contrib/auth/models.py in create_row_level_permission, line 58 Is there a problem with my understanding of things here? Is there a reason that RowLevelPermissions shouldn't be allowed on models with a OneToOne? I can see the technical reason in the code, namely that the code assumes we have an 'id' field. But is that a correct assumption? Jay P. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
RowLevelPermissions SQL error
More playing with the per-object branch, and just received this error:
Traceback (most recent call last):
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/core/handlers/base.py"
in get_response
74. response = callback(request, *callback_args, **callback_kwargs)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/contrib/admin/views/decorators.py"
in _checklogin
55. return view_func(request, *args, **kwargs)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/views/decorators/cache.py"
in _wrapped_view_func
39. response = view_func(request, *args, **kwargs)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/contrib/admin/views/main.py"
in change_list
775. cl = ChangeList(request, model)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/contrib/admin/views/main.py"
in __init__
585. self.query_set = self.get_query_set()
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/contrib/admin/views/main.py"
in get_query_set
697. self.opts.get_change_permission()))
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/contrib/auth/models.py"
in get_model_list
88. id_list = [o['model_id'] for o in user_model_ids] +
[o['model_id'] for o in group_model_ids]
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/db/models/query.py"
in __iter__
103. return iter(self._get_data())
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/db/models/query.py"
in _get_data
430. self._result_cache = list(self.iterator())
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/db/models/query.py"
in iterator
528. cursor.execute("SELECT " + (self._distinct and "DISTINCT " or
"") + ",".join(select) + sql, params)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/db/backends/util.py"
in execute
12. return self.cursor.execute(sql, params)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/db/backends/mysql/base.py"
in execute
35. return self.cursor.execute(sql, params)
File "/Users/jayparlar/Library/Python2.4/site-packages/MySQLdb/cursors.py"
in execute
163. self.errorhandler(self, exc, value)
File "/Users/jayparlar/Library/Python2.4/site-packages/MySQLdb/connections.py"
in defaulterrorhandler
35. raise errorclass, errorvalue
ProgrammingError at /admin/members/role/
(1064, "You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near ') AND `auth_rowlevelpermission`.`owner_ct_id` = 2)' at line 1")
Here's the setup:
I have a model defined as follows:
class Role(models.Model):
position = models.IntegerField(choices=MEMBERSHIP_STATUS)
class Admin:
grant_change_row_level_perm=True
show_all_rows = False
class Meta:
row_level_permissions = True
I have a user "q2" with the general permissions "Can add role" and
"Can delete role".
I log into the Admin with "q2", and add a new row. Works fine. Go back
to the main admin page, and click on "Roles", and I get the error
above.
Jay P.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
