load template tag library
Hi all, Can anybody explain why template tag libraries are loaded from *inside* a template? The more I work with them, the more I get the feeling that specifying which template tags are available in a template should be specified in the view-code (or more general: the thing that loads/renders the template). Why would I, as a back-end developer, make *all* of my template tags available to the front-end developer in *all* templates? A great benefit of moving the template tag library loading to code, would be that the template language could also be safely used in CharFields/TextFields, without the risk of users using unwanted template tags. Of course, for backward compatibility, this can't be changed. The thing I'm most interested in, though, is restricting the template tag libraries that can be used in a template from my view-code. This can be done in a backward compatible way. Opinions? Cheers, Roald -- 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: mark_safe(media) in django admin
i've created a ticket https://code.djangoproject.com/ticket/17239 sorry but i'm new, i'would like to contribute. let me know if it's fine. On 15 Nov, 07:02, Aymeric Augustin wrote: > On 14 nov. 2011, at 23:15, Ric wrote: > > > a minor bug in django admin. > > Could you open a ticket in our bug tracker? > > https://code.djangoproject.com/newticket > > Thanks, > > -- > Aymeric Augustin. -- 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.
add view_permission
i've been thinking about a new django admin feature, that could be backward implemented it's about adding a view permission for models so we can have 1.change_permission 2.delete_permission 3.add_permission and 4.view_permission in the changelist_view view_permission allow user to see the changelist, but user still need a change_permission to use the list_editable. in the change_view, having a view_permission allow to see the object, but the method get_read_only_fields returns all the fields. in every case a POST request raise a PermissionDenied if the user do not have a change_permission, but allows GET request if user got a view_permission view_permission could be added on the next syncdb... -- 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.
Forbiden 403 error
I am new to both python and Django but I have been programming for more than 20 years so I am teaching myself this stuff. I came across an old training video that I have been going through. This training has you develop a website that can create web pages. I got everything right so far but I just got to the point where you are to save off your changes to create a new file and I am getting the 403 Forbidden error associated with a POST to my connection. The error specifically states "CSRF token missing or incorrect." Now I am currently reading through this stuff on the Django web site and I find that you must have it at the top of your "views" but can someone explain in more plain language why this isn't on by default and what the problem really is here? In reading the info on the Django site it seems backwards so I must be missing something. When I read it, it sounds like you have to add this to "gain" the protection not remove it. What I think I am seeing is my system is not allowing my browser to write new files so I have the protection by default and I need to add this stuff in order to remove the protection. That makes sense to me but seems backwards from what I read on the Django site. I am very confused by this. Any help would be appreciated. -- View this message in context: http://old.nabble.com/Forbiden-403-error-tp32856616p32856616.html Sent from the django-developers mailing list archive at Nabble.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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Forbiden 403 error
Hello there. You've posted to django-developers which is a mailing list of development of the django project itself. For help using django, please post to django-users. On Wed, Nov 16, 2011 at 1:25 PM, Djano_newb wrote: > > I am new to both python and Django but I have been programming for more than > 20 years so I am teaching myself this stuff. I came across an old training > video that I have been going through. This training has you develop a > website that can create web pages. I got everything right so far but I just > got to the point where you are to save off your changes to create a new file > and I am getting the 403 Forbidden error associated with a POST to my > connection. The error specifically states "CSRF token missing or > incorrect." > > Now I am currently reading through this stuff on the Django web site and I > find that you must have it at the top of your "views" but can someone > explain in more plain language why this isn't on by default and what the > problem really is here? In reading the info on the Django site it seems > backwards so I must be missing something. When I read it, it sounds like > you have to add this to "gain" the protection not remove it. What I think I > am seeing is my system is not allowing my browser to write new files so I > have the protection by default and I need to add this stuff in order to > remove the protection. That makes sense to me but seems backwards from what > I read on the Django site. I am very confused by this. Any help would be > appreciated. > -- > View this message in context: > http://old.nabble.com/Forbiden-403-error-tp32856616p32856616.html > Sent from the django-developers mailing list archive at Nabble.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 > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Justin Holmes Head Instructor, SlashRoot Collective SlashRoot: Coffee House and Tech Dojo 60 Main Street New Paltz, NY 12561 845.633.8330 -- 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: add view_permission
I would benefit from this. With administration systems I build with Django I generally have to add my own 'view_foo' permission to each model. +1 On 17/11/2011, at 2:47 AM, Ric wrote: > i've been thinking about a new django admin feature, that could be > backward implemented > > it's about adding a view permission for models > > so we can have > > 1.change_permission > 2.delete_permission > 3.add_permission > and > 4.view_permission > > in the changelist_view view_permission allow user to see the > changelist, but user still need a change_permission to use the > list_editable. > in the change_view, having a view_permission allow to see the object, > but the method get_read_only_fields returns all the fields. > > in every case a POST request raise a PermissionDenied if the user do > not have a change_permission, but allows GET request if user got a > view_permission > > view_permission could be added on the next syncdb... > > -- > 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. > -- 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: add view_permission
yes i would use it too, because i've got a lot of models with a view permission to the final user but with no change permission. it could be archived with backward compatibility, because by default a user has got no view permission view permission can be added with a syncdb, and user must add them from the admin panel don't see backward issue, it would be a nice feature. On 16 Nov, 19:47, Bradley Ayers wrote: > I would benefit from this. With administration systems I build with Django I > generally have to add my own 'view_foo' permission to each model. +1 > > On 17/11/2011, at 2:47 AM, Ric wrote: > > > > > > > > > i've been thinking about a new django admin feature, that could be > > backward implemented > > > it's about adding a view permission for models > > > so we can have > > > 1.change_permission > > 2.delete_permission > > 3.add_permission > > and > > 4.view_permission > > > in the changelist_view view_permission allow user to see the > > changelist, but user still need a change_permission to use the > > list_editable. > > in the change_view, having a view_permission allow to see the object, > > but the method get_read_only_fields returns all the fields. > > > in every case a POST request raise a PermissionDenied if the user do > > not have a change_permission, but allows GET request if user got a > > view_permission > > > view_permission could be added on the next syncdb... > > > -- > > 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 > > athttp://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-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: add view_permission
Hi Ric, This feature request is quite common, and it's tracked here: https://code.djangoproject.com/ticket/8936 A few people talked to me since I wrote the GSoC project description linked in comment #5, but I don't think anyone is actively working on this. Since we deprecated databrowse, the problem is much simpler than what I described. It's probably still more complicated than what a patch can handle. If you want to work on this ticket, I suggest to: a) read the contributing guide in the docs (if you haven't yet), b) review related discussions on this mailing list, and search for related tickets in Trac, c) post a more detailed proposal here, d) fork the bitbucket or github mirror and work on your clone, e) track your progress by commenting on the ticket or on the mailing list. Be aware that this isn't an easy ticket — you may prefer to start with smaller issues and tackle this when you're more at ease with our development process. Best regards, -- Aymeric Augustin. On 16 nov. 2011, at 17:47, Ric wrote: > i've been thinking about a new django admin feature, that could be > backward implemented > > it's about adding a view permission for models > > so we can have > > 1.change_permission > 2.delete_permission > 3.add_permission > and > 4.view_permission > > in the changelist_view view_permission allow user to see the > changelist, but user still need a change_permission to use the > list_editable. > in the change_view, having a view_permission allow to see the object, > but the method get_read_only_fields returns all the fields. > > in every case a POST request raise a PermissionDenied if the user do > not have a change_permission, but allows GET request if user got a > view_permission > > view_permission could be added on the next syncdb... > > -- > 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. > -- 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: Error in formfield in django.db.models.field
should i have to open a ticket?
On 14 Nov, 23:19, Ric wrote:
> form_class is not in kwargs if the method is declared like this
>
> def formfield(self, form_class=forms.CharField, **kwargs):
>
> a possible solution is to use a code like this
>
> def formfield(self, **kwargs):
> form_class = kwargs.pop("form_class", self.choices and
> forms.TypedChoiceField or forms.CharField)
>
> in that way is no form_class is passed, a default form_class is
> defined (TypedChoiceField or CharField)
>
> On 14 Nov, 21:22, Ric wrote:
>
>
>
>
>
>
>
> > yes but definitely not the current code, because i cannot subclass
> > with super
>
> > On 14 Nov, 15:46, ptone wrote:
>
> > > On Nov 13, 11:55 pm, Ric wrote:
>
> > > > the field class define this code
>
> > > > def formfield(self, form_class=forms.CharField, **kwargs):
> > > > """
> > > > Returns a django.forms.Field instance for this database Field.
> > > > """
> > > > defaults = {'required': not self.blank,
> > > > 'label': capfirst(self.verbose_name),
> > > > 'help_text': self.help_text}
> > > > if self.has_default():
> > > > if callable(self.default):
> > > > defaults['initial'] = self.default
> > > > defaults['show_hidden_initial'] = True
> > > > else:
> > > > defaults['initial'] = self.get_default()
> > > > if self.choices:
> > > > # Fields with choices get special treatment.
> > > > include_blank = (self.blank or
> > > > not (self.has_default() or 'initial' in
> > > > kwargs))
> > > > defaults['choices'] =
> > > > self.get_choices(include_blank=include_blank)
> > > > defaults['coerce'] = self.to_python
> > > > if self.null:
> > > > defaults['empty_value'] = None
> > > > form_class = forms.TypedChoiceField
> > > > # Many of the subclass-specific formfield arguments
> > > > (min_value,
> > > > # max_value) don't apply for choice fields, so be sure to
> > > > only pass
> > > > # the values that TypedChoiceField will understand.
> > > > for k in kwargs.keys():
> > > > if k not in ('coerce', 'empty_value', 'choices',
> > > > 'required',
> > > > 'widget', 'label', 'initial',
> > > > 'help_text',
> > > > 'error_messages', 'show_hidden_initial'):
> > > > del kwargs[k]
> > > > defaults.update(kwargs)
> > > > return form_class(**defaults)
>
> > > > this code says
> > > > if self.choices:
> > > > form_class = forms.TypedChoiceField
>
> > > > this means that if you have a field that got choices, even if you pass
> > > > during the super an argument different than forms.TypedChoiceField,
> > > > you'll always get forms.TypedChoiceField
>
> > > > must be defaults["form_class"] = forms.TypedChoiceField
>
> > > do you mean something like:
>
> > > if self.choices:
> > > if 'form_class' in defaults:
> > > form_class = defaults['form_class']
> > > else:
> > > form_class = forms.TypedChoiceField
>
> > > -Preston
> > > form_class =
--
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: load template tag library
On Nov 16, 1:12 am, Roald wrote: > Hi all, > > Can anybody explain why template tag libraries are loaded from > *inside* a template? The more I work with them, the more I get the > feeling that specifying which template tags are available in a > template should be specified in the view-code (or more general: the > thing that loads/renders the template). Such as a TemplateEngine...? This seems a good candidate feature for: https://code.djangoproject.com/ticket/17093 >Why would I, as a back-end > developer, make *all* of my template tags available to the front-end > developer in *all* templates? > > A great benefit of moving the template tag library loading to code, > would be that the template language could also be safely used in > CharFields/TextFields, without the risk of users using unwanted > template tags. > > Of course, for backward compatibility, this can't be changed. The > thing I'm most interested in, though, is restricting the template tag > libraries that can be used in a template from my view-code. This can > be done in a backward compatible way. > > Opinions? > > Cheers, Roald -- 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: add view_permission
ok i can give a try... maybe it's difficult, not to much. i have to see inline models, and give the right behavior so from github i can fork django 1.3.1, but actually i'm working with the latest version. should i fork the lastest? On 16 Nov, 20:21, Aymeric Augustin wrote: > Hi Ric, > > This feature request is quite common, and it's tracked > here:https://code.djangoproject.com/ticket/8936 > > A few people talked to me since I wrote the GSoC project description linked > in comment #5, but I don't think anyone is actively working on this. > > Since we deprecated databrowse, the problem is much simpler than what I > described. It's probably still more complicated than what a patch can handle. > > If you want to work on this ticket, I suggest to: > a) read the contributing guide in the docs (if you haven't yet), > b) review related discussions on this mailing list, and search for related > tickets in Trac, > c) post a more detailed proposal here, > d) fork the bitbucket or github mirror and work on your clone, > e) track your progress by commenting on the ticket or on the mailing list. > > Be aware that this isn't an easy ticket — you may prefer to start with > smaller issues and tackle this when you're more at ease with our development > process. > > Best regards, > > -- > Aymeric Augustin. > > On 16 nov. 2011, at 17:47, Ric wrote: > > > > > > > > > i've been thinking about a new django admin feature, that could be > > backward implemented > > > it's about adding a view permission for models > > > so we can have > > > 1.change_permission > > 2.delete_permission > > 3.add_permission > > and > > 4.view_permission > > > in the changelist_view view_permission allow user to see the > > changelist, but user still need a change_permission to use the > > list_editable. > > in the change_view, having a view_permission allow to see the object, > > but the method get_read_only_fields returns all the fields. > > > in every case a POST request raise a PermissionDenied if the user do > > not have a change_permission, but allows GET request if user got a > > view_permission > > > view_permission could be added on the next syncdb... > > > -- > > 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 > > athttp://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-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: add view_permission
at a first look, the big file to patch is django.contrib.admin.options i need also to add a method to django.db.models.options def get_view_permission(self): return 'view_%s' % self.object_name.lower() so maybe it's better to work only on options.py and make a .diff, right? On 16 Nov, 20:43, Ric wrote: > ok i can give a try... > > maybe it's difficult, not to much. i have to see inline models, and > give the right behavior > > so from github i can fork django 1.3.1, but actually i'm working with > the latest version. > > should i fork the lastest? > > On 16 Nov, 20:21, Aymeric Augustin > > > > > > > > wrote: > > Hi Ric, > > > This feature request is quite common, and it's tracked > > here:https://code.djangoproject.com/ticket/8936 > > > A few people talked to me since I wrote the GSoC project description linked > > in comment #5, but I don't think anyone is actively working on this. > > > Since we deprecated databrowse, the problem is much simpler than what I > > described. It's probably still more complicated than what a patch can > > handle. > > > If you want to work on this ticket, I suggest to: > > a) read the contributing guide in the docs (if you haven't yet), > > b) review related discussions on this mailing list, and search for related > > tickets in Trac, > > c) post a more detailed proposal here, > > d) fork the bitbucket or github mirror and work on your clone, > > e) track your progress by commenting on the ticket or on the mailing list. > > > Be aware that this isn't an easy ticket — you may prefer to start with > > smaller issues and tackle this when you're more at ease with our > > development process. > > > Best regards, > > > -- > > Aymeric Augustin. > > > On 16 nov. 2011, at 17:47, Ric wrote: > > > > i've been thinking about a new django admin feature, that could be > > > backward implemented > > > > it's about adding a view permission for models > > > > so we can have > > > > 1.change_permission > > > 2.delete_permission > > > 3.add_permission > > > and > > > 4.view_permission > > > > in the changelist_view view_permission allow user to see the > > > changelist, but user still need a change_permission to use the > > > list_editable. > > > in the change_view, having a view_permission allow to see the object, > > > but the method get_read_only_fields returns all the fields. > > > > in every case a POST request raise a PermissionDenied if the user do > > > not have a change_permission, but allows GET request if user got a > > > view_permission > > > > view_permission could be added on the next syncdb... > > > > -- > > > 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 > > > athttp://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-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: load template tag library
On Nov 16, 8:40 pm, ptone wrote: > On Nov 16, 1:12 am, Roald wrote: > > > Hi all, > > > Can anybody explain why template tag libraries are loaded from > > *inside* a template? The more I work with them, the more I get the > > feeling that specifying which template tags are available in a > > template should be specified in the view-code (or more general: the > > thing that loads/renders the template). > > Such as a TemplateEngine...? Yes, exactly! So what would be the procedure for proposing this? Use the mailing list, or adding it to the ticket? -- 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: add view_permission
Hi Ric, I've noticed that you're posting a lot on this mailing list. Please remember that each email sent here is broadcasted to around 7000 people, each of whom will need a few seconds to decide if it's interesting. You're expected to do some research and to structure your thoughts and questions before posting. From my own experience, it's unusual to write an email for django-developers in less than an hour, and it can even take several days. "Stream of thought" messages aren't appropriate; if you want to chat, please join the #django-dev on FreeNode. Thanks for your understanding! -- Aymeric Augustin. On 16 nov. 2011, at 20:51, Ric wrote: > at a first look, the big file to patch is django.contrib.admin.options > > i need also to add a method to django.db.models.options > > def get_view_permission(self): >return 'view_%s' % self.object_name.lower() > > so maybe it's better to work only on options.py and make a .diff, > right? > > On 16 Nov, 20:43, Ric wrote: >> ok i can give a try... >> >> maybe it's difficult, not to much. i have to see inline models, and >> give the right behavior >> >> so from github i can fork django 1.3.1, but actually i'm working with >> the latest version. >> >> should i fork the lastest? >> >> On 16 Nov, 20:21, Aymeric Augustin >> >> >> >> >> >> >> >> wrote: >>> Hi Ric, >> >>> This feature request is quite common, and it's tracked >>> here:https://code.djangoproject.com/ticket/8936 >> >>> A few people talked to me since I wrote the GSoC project description linked >>> in comment #5, but I don't think anyone is actively working on this. >> >>> Since we deprecated databrowse, the problem is much simpler than what I >>> described. It's probably still more complicated than what a patch can >>> handle. >> >>> If you want to work on this ticket, I suggest to: >>> a) read the contributing guide in the docs (if you haven't yet), >>> b) review related discussions on this mailing list, and search for related >>> tickets in Trac, >>> c) post a more detailed proposal here, >>> d) fork the bitbucket or github mirror and work on your clone, >>> e) track your progress by commenting on the ticket or on the mailing list. >> >>> Be aware that this isn't an easy ticket — you may prefer to start with >>> smaller issues and tackle this when you're more at ease with our >>> development process. >> >>> Best regards, >> >>> -- >>> Aymeric Augustin. >> >>> On 16 nov. 2011, at 17:47, Ric wrote: >> i've been thinking about a new django admin feature, that could be backward implemented >> it's about adding a view permission for models >> so we can have >> 1.change_permission 2.delete_permission 3.add_permission and 4.view_permission >> in the changelist_view view_permission allow user to see the changelist, but user still need a change_permission to use the list_editable. in the change_view, having a view_permission allow to see the object, but the method get_read_only_fields returns all the fields. >> in every case a POST request raise a PermissionDenied if the user do not have a change_permission, but allows GET request if user got a view_permission >> view_permission could be added on the next syncdb... >> -- 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 athttp://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-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. > -- 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: add view_permission
fine i'll keep in mind. On 16 Nov, 22:17, Aymeric Augustin wrote: > Hi Ric, > > I've noticed that you're posting a lot on this mailing list. Please remember > that each email sent here is broadcasted to around 7000 people, each of whom > will need a few seconds to decide if it's interesting. > > You're expected to do some research and to structure your thoughts and > questions before posting. From my own experience, it's unusual to write an > email for django-developers in less than an hour, and it can even take > several days. "Stream of thought" messages aren't appropriate; if you want to > chat, please join the #django-dev on FreeNode. > > Thanks for your understanding! > > -- > Aymeric Augustin. > > On 16 nov. 2011, at 20:51, Ric wrote: > > > > > > > > > at a first look, the big file to patch is django.contrib.admin.options > > > i need also to add a method to django.db.models.options > > > def get_view_permission(self): > > return 'view_%s' % self.object_name.lower() > > > so maybe it's better to work only on options.py and make a .diff, > > right? > > > On 16 Nov, 20:43, Ric wrote: > >> ok i can give a try... > > >> maybe it's difficult, not to much. i have to see inline models, and > >> give the right behavior > > >> so from github i can fork django 1.3.1, but actually i'm working with > >> the latest version. > > >> should i fork the lastest? > > >> On 16 Nov, 20:21, Aymeric Augustin > > >> wrote: > >>> Hi Ric, > > >>> This feature request is quite common, and it's tracked > >>> here:https://code.djangoproject.com/ticket/8936 > > >>> A few people talked to me since I wrote the GSoC project description > >>> linked in comment #5, but I don't think anyone is actively working on > >>> this. > > >>> Since we deprecated databrowse, the problem is much simpler than what I > >>> described. It's probably still more complicated than what a patch can > >>> handle. > > >>> If you want to work on this ticket, I suggest to: > >>> a) read the contributing guide in the docs (if you haven't yet), > >>> b) review related discussions on this mailing list, and search for > >>> related tickets in Trac, > >>> c) post a more detailed proposal here, > >>> d) fork the bitbucket or github mirror and work on your clone, > >>> e) track your progress by commenting on the ticket or on the mailing list. > > >>> Be aware that this isn't an easy ticket — you may prefer to start with > >>> smaller issues and tackle this when you're more at ease with our > >>> development process. > > >>> Best regards, > > >>> -- > >>> Aymeric Augustin. > > >>> On 16 nov. 2011, at 17:47, Ric wrote: > > i've been thinking about a new django admin feature, that could be > backward implemented > > it's about adding a view permission for models > > so we can have > > 1.change_permission > 2.delete_permission > 3.add_permission > and > 4.view_permission > > in the changelist_view view_permission allow user to see the > changelist, but user still need a change_permission to use the > list_editable. > in the change_view, having a view_permission allow to see the object, > but the method get_read_only_fields returns all the fields. > > in every case a POST request raise a PermissionDenied if the user do > not have a change_permission, but allows GET request if user got a > view_permission > > view_permission could be added on the next syncdb... > > -- > 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 > athttp://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-developers@googlegroups.com. > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://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-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: load template tag library
On 16/11/11 09:12, Roald wrote:
> Hi all,
>
> Can anybody explain why template tag libraries are loaded from
> *inside* a template? The more I work with them, the more I get the
> feeling that specifying which template tags are available in a
> template should be specified in the view-code (or more general: the
> thing that loads/renders the template). Why would I, as a back-end
> developer, make *all* of my template tags available to the front-end
> developer in *all* templates?
>
> A great benefit of moving the template tag library loading to code,
> would be that the template language could also be safely used in
> CharFields/TextFields, without the risk of users using unwanted
> template tags.
>
> Of course, for backward compatibility, this can't be changed. The
> thing I'm most interested in, though, is restricting the template tag
> libraries that can be used in a template from my view-code. This can
> be done in a backward compatible way.
>
> Opinions?
>From my perspective, putting the template tag libraries in the view is
absolutely the wrong thing to do, for a number of reasons:
1) If I'm reading a template and come across a template tag I don't
understand, I have to go and find the view it is called from to work out
what template tag library it might be from. The information is much
better off in the template.
2) A single template might be used by multiple views. If views are
responsible for setting the libraries available, they now have duplicate
content.
3) If it was done this way, then the available libraries would have to
be inherited by included templates, and templates that are 'extended
from'. This makes things even worse for chasing down which template tag
libraries are in use, especially as a single template can be included
from multiple places. If you add in the fact that a tag from custom
template tag library can shadow a builtin, and the deliberate mechanism
we have for choosing a new version ({% load url from future %}), things
are getting pretty diabolical.
Template tags essentially form part of the syntax of the template, and
putting that information outside the template really doesn't make sense.
As for the need to limit which libraries are allowed for a template, my
solution would be to do this:
{% load foo bar baz %} {# No others allowed for this template #}
Front-end developers are on the same team. If they refuse to follow
instructions like that, you should sack them.
You shouldn't be using the template system in situations where you have
people who are not trusted, because it simply does not have the security
necessary for it to be made available to potentially malicious users. It
was never designed with that in mind, and would probably have dozens of
major security flaws if you use it in that way. (The protection that
exists against use of unsafe methods being called is protection against
*accidental* use of those methods, not against malicious users).
So, if this feature request (restricting the available template tag
libraries) is part of a security feature, I'm -1 on it, because it
implies an existing level of security in the template system that
doesn't exist. To put it another way, if your use case is "allow end
users to use the template system safely", this feature wouldn't come
close to doing that. If your use case is "stop front-end developers
deliberately doing naughty things", I'd say the solution can't be a
technical one.
Regards,
Luke
--
You meet a lot of smart guys with stupid wives, but you almost
never meet a smart woman with a stupid husband. (Erica Jong)
Luke Plant || http://lukeplant.me.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-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: add view_permission
ok this is my last message, i swear! i've created a new options.py file and a .diff, and i've attached it to the ticket you send to me. i've tested it and it works, it's pretty basic and there is more work to do. what i've done is to add a method has_view_permission, and check a view permission in every view i also created a get_list_editable, and i add in get_list_editable and in get_readonly_fields a check, and it returns original read_only and list_editable only if user has got a change_pemission i also raise a permission error every time there is a post request and user do not have a change_permission a also ask for view_permission in history_view. todo: fix inlines fix submit_row add a opts.has_view_permission() -- 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.
Can we drop Oracle 9 support?
Hi, Oracle 10 has been released in 2003 -- the same year as Python 2.3, which is no longer supported by Django. Oracle 9 is essentially end-of-life'd -- Oracle will not provide patches for it, even for critical bugs, and even if you pay extra. This is since July 2010, according to http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf Support for Oracle 9 is a very minor thing in the backend code itself -- only a handful of lines -- but these lines execute a command on the backend to get the server version, at every connection, and our data indicates this command does affect performance. You might expect that it just looks up a constant, but in fact it is a stored procedure that looks in several places to calculate not just the software version, but also the interface compliance level. In the backend, the version info is only used to tell if we're still on 9. If we drop 9 support, we don't need that anymore. For the benefit of those who need to know the version (e.g. 3rd-party code which uses specific Oracle 11 features), I propose we change oracle_version from an attribute on the connection that is filled at connection time, to a property that proxies the cx-oracle connection property. That property is memoized (at the connection-object level) anyway, so for code that relies on it, the only difference would be in when the server statements are executed, while for the rest (most?) of us, the statements will just not be run. So -- can we drop Oracle 9? Should I open a ticket for it? Shai. -- 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: load template tag library
On Wed, Nov 16, 2011 at 5:12 PM, Roald wrote: > Hi all, > > Can anybody explain why template tag libraries are loaded from > *inside* a template? The more I work with them, the more I get the > feeling that specifying which template tags are available in a > template should be specified in the view-code (or more general: the > thing that loads/renders the template). Why would I, as a back-end > developer, make *all* of my template tags available to the front-end > developer in *all* templates? I'm afraid I don't follow how it would make sense for template tags to be loaded anywhere *except* inside a template. * The view constructs the context data that is to be available for rendering. * The template determines how that context data will be rendered. * A template tag is a block of functionality that can be used to manipulate the display of data. The decision to use a particular template tag is entirely a front-end decision. True, it might require some coordination with backend developers to provide specific functionality (e.g., writing a specific data transformation, or writing a tag to extract specific data), but I fail to see how that division of labor suggests that the decision to make a template tag available at all should be controlled by the backend developer. > A great benefit of moving the template tag library loading to code, > would be that the template language could also be safely used in > CharFields/TextFields, without the risk of users using unwanted > template tags. If I'm understanding this correctly, your use case here is putting template content into a CharField or TextField, but you don't want to be subjected to injection-style attacks from on user content. This strikes me as a pretty obscure edge case to drive the design of the template language. > Of course, for backward compatibility, this can't be changed. The > thing I'm most interested in, though, is restricting the template tag > libraries that can be used in a template from my view-code. This can > be done in a backward compatible way. As with Luke, count me as a -1 on this. Luke's final paragraph sums up the situation nicely, IMHO: if your use case is "allow end users to use the template system safely", this feature wouldn't come close to doing that. If your use case is "stop front-end developers deliberately doing naughty things", I'd say the solution can't be a technical one. 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Can we drop Oracle 9 support?
On Wed, Nov 16, 2011 at 4:55 PM, Shai Berger wrote: > Hi, > > Oracle 10 has been released in 2003 -- the same year as Python 2.3, which is > no longer supported by Django. > > Oracle 9 is essentially end-of-life'd -- Oracle will not provide patches for > it, even for critical bugs, and even if you pay extra. This is since July > 2010, according to > http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf > > Support for Oracle 9 is a very minor thing in the backend code itself -- only > a handful of lines -- but these lines execute a command on the backend to get > the server version, at every connection, and our data indicates this command > does affect performance. You might expect that it just looks up a constant, > but in fact it is a stored procedure that looks in several places to calculate > not just the software version, but also the interface compliance level. > > In the backend, the version info is only used to tell if we're still on 9. If > we drop 9 support, we don't need that anymore. > > For the benefit of those who need to know the version (e.g. 3rd-party code > which uses specific Oracle 11 features), I propose we change oracle_version > from an attribute on the connection that is filled at connection time, to a > property that proxies the cx-oracle connection property. That property is > memoized (at the connection-object level) anyway, so for code that relies on > it, the only difference would be in when the server statements are executed, > while for the rest (most?) of us, the statements will just not be run. > > So -- can we drop Oracle 9? Should I open a ticket for it? -0. This isn't really like deprecating old Python versions, which is necessary to keep the codebase unified while gaining access to new features. We have a certain subset of SQL that we need to be supported by a backend, and that subset doesn't grow very quickly. Django works on Oracle 9 with the one exception of regex query filters, and that status is unlikely to change with new Oracle versions. The main reason to drop Oracle 9 support would be to support more recent features, and I'm not aware of anything particularly compelling for use by Django. I would also want to poll the community before dropping support, to verify that few users are still using Oracle 9 with Django. We still have some Oracle 9 databases where I work, although none running Django at this point. I've even (recently) heard of organizations still stuck on Oracle 8. The version check that you point out does not really need to be done on every connection, I think. If we make a connection and find one version and then later make a new connection using the same DatabaseWrapper, we expect the database to still be the same version. I would propose that instead of dropping support, we make this check once per DatabaseWrapper per thread, in the same way that the LIKE operators are already configured. Cheers, Ian -- 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: load template tag library
I second what Luke and Russ have already said. If what you're interested in is a way to securely allow users to enter template code into the database, you can just write a custom field that validates its input for security problems. Here's a third-party implementation of a validator for such a field: https://github.com/ithinksw/philo/blob/master/philo/validators.py#L106 This particular implementation: - lets you explicitly allow particular tags (in which case all other tags are disallowed for the field) - lets you explicitly disallow particular tags (in which case all other tags are allowed for the field) - disallows the load, extends, include, and debug template tags by default, but lets the backend developer specify the field as "insecure" if they want to. My point being - if what you want is to let people specify template code in database fields, there are ways to make it secure without rewriting the template engine. On Nov 16, 4:04 pm, Russell Keith-Magee wrote: > On Wed, Nov 16, 2011 at 5:12 PM, Roald wrote: > > Hi all, > > > Can anybody explain why template tag libraries are loaded from > > *inside* a template? The more I work with them, the more I get the > > feeling that specifying which template tags are available in a > > template should be specified in the view-code (or more general: the > > thing that loads/renders the template). Why would I, as a back-end > > developer, make *all* of my template tags available to the front-end > > developer in *all* templates? > > I'm afraid I don't follow how it would make sense for template tags to > be loaded anywhere *except* inside a template. > > * The view constructs the context data that is to be available for rendering. > > * The template determines how that context data will be rendered. > > * A template tag is a block of functionality that can be used to > manipulate the display of data. > > The decision to use a particular template tag is entirely a front-end > decision. True, it might require some coordination with backend > developers to provide specific functionality (e.g., writing a specific > data transformation, or writing a tag to extract specific data), but I > fail to see how that division of labor suggests that the decision to > make a template tag available at all should be controlled by the > backend developer. > > > A great benefit of moving the template tag library loading to code, > > would be that the template language could also be safely used in > > CharFields/TextFields, without the risk of users using unwanted > > template tags. > > If I'm understanding this correctly, your use case here is putting > template content into a CharField or TextField, but you don't want to > be subjected to injection-style attacks from on user content. This > strikes me as a pretty obscure edge case to drive the design of the > template language. > > > Of course, for backward compatibility, this can't be changed. The > > thing I'm most interested in, though, is restricting the template tag > > libraries that can be used in a template from my view-code. This can > > be done in a backward compatible way. > > As with Luke, count me as a -1 on this. Luke's final paragraph sums up > the situation nicely, IMHO: > > if your use case is "allow end users to use the template > system safely", this feature wouldn't come close to doing that. > If your use case is "stop front-end developers deliberately doing > naughty things", I'd say the solution can't be a technical one. > > 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
ModelAdmin not allowing dynamic fields to be set in __init__. Is it intended behavior?
Hi all, I discovered yesterday that ModelAdmin does not display fields set in the __init__ of the custom form. This is due to django.contrib.admin.ModelAdmin.get_fieldsets only looking at the base_field variable of the form *class' instead of the form instance. This can be circumvented with a factory or by using a metaclass. I implemented a metaclass version of this just out of curiosity: https://gist.github.com/1370436 My question is that is this intended behavior or is the problem outside the scope of the django.contrib.admin? If it it is I'm fine with that, though I find it a bit confusing that the dynamic form field creation tips do not apply to forms used in admin. If it's not, I'm more than happy to look into the issue deeper and try to work a patch. However, the patch might be quite intrusive and change a lot of the internal behavior of the django.contrib.admin. Looking forward on your feedback! - Jyrki -- 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.
