Re: Attach a technincal html response to email on server error
oh fantastic... but i read about security issue... and what about create a model, save the traceback in the db, and reopen it from the admin? On 12 Nov, 03:39, Karen Tracey wrote: > On Fri, Nov 11, 2011 at 9:35 PM, Ric wrote: > > yeah i know it can be done... > > > i can try to write it in future... it can be a subclass of something, > > i have to open the code. > > You don't have to write anything, you just have to set include_html=True in > the config for the Django-provided admin email handler. See: > > https://docs.djangoproject.com/en/1.3/topics/logging/#django.utils.lo... > > Karen -- 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: Attach a technincal html response to email on server error
Hi Riccardo, On Sun, Nov 13, 2011 at 2:51 PM, Ric wrote: > > and what about create a model, save the traceback in the db, and > reopen it from the admin? > You should have a look at Sentry[1]. It does exactly what you want, and much more. Easily one of the best tools to monitor errors of your webapp. [1]: http://sentry.readthedocs.org/en/latest/index.html -- 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: Attach a technincal html response to email on server error
yes of course i've read it in the documentation... i'v snv the code right now! sorry, i missed it. On 13 Nov, 15:03, Benjamin Wohlwend wrote: > Hi Riccardo, > > On Sun, Nov 13, 2011 at 2:51 PM, Ric wrote: > > > and what about create a model, save the traceback in the db, and > > reopen it from the admin? > > You should have a look at Sentry[1]. It does exactly what you want, > and much more. Easily one of the best tools to monitor errors of your > webapp. > > [1]:http://sentry.readthedocs.org/en/latest/index.html -- 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: Attach a technincal html response to email on server error
Sounds similar to what django-sentry already provides: http://blog.disqus.com/post/1178923988/django-sentry (we may want to move this discussion to django-users) On Sun, Nov 13, 2011 at 7:51 AM, Ric wrote: > oh fantastic... but i read about security issue... > > and what about create a model, save the traceback in the db, and > reopen it from the admin? > > On 12 Nov, 03:39, Karen Tracey wrote: >> On Fri, Nov 11, 2011 at 9:35 PM, Ric wrote: >> > yeah i know it can be done... >> >> > i can try to write it in future... it can be a subclass of something, >> > i have to open the code. >> >> You don't have to write anything, you just have to set include_html=True in >> the config for the Django-provided admin email handler. See: >> >> https://docs.djangoproject.com/en/1.3/topics/logging/#django.utils.lo... >> >> Karen > > -- > 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: Multi-DB support within transaction middleware
Before voting for more magic to the transaction middleware, I'd vote to remove it altogether. Explicit is surely better than implicit in this case. The admin already uses commit_on_success, etc. On Oct 18, 1:22 pm, David Winterbottom wrote: > The current implementation of django.middleware.TransactionMiddleware does > not create a transaction for each database, only the default one > defined by DEFAULT_DB_ALIAS > -https://code.djangoproject.com/browser/django/trunk/django/db/utils.py. > Shouldn't the middleware manage a transaction for each database defined in > the DATABASES setting? > > I discovered this while debugging some caching issues with the johnnycache > library, which saves cached querysets when committing. In my case, all > requests to databases other than default were not being cached. > > Happy to supply a patch and tests if this is sensible. > -- > *Dr. David Winterbottom* > Head of Programming > > Tangent Labs > 84-86 Great Portland Street > London W1W 7NR > England, 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.
'default' option for FileField - potential feature, bug, or lack of documentation?
This is somewhat of a design decision needed. Currently it seems that FileField doesn't do anything interesting with the "default" option to the field. It certainly could, but there is nothing in the documentation about what default means in the context of a FileField. It seems rather brain-dead currently in that it just lets the parent Field class stick the string in the DB as a raw value. what should it do? check if the value is a valid path to a file and then use that? https://code.djangoproject.com/ticket/17224 -Preston -- 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.
Wiki page on global state
Following several discussions on IRC where I realized my understanding of the issue was far from complete, I did some reading and have done my best to summarize what I understand to be the current state of affairs: https://code.djangoproject.com/wiki/GlobalState The idea is that this page could be improved and serve two main purposes: 1) A place to point people to when they are confused about how the reliance on global state effects Django, or when someone bumps up to some specific area where global state is effecting their use of Django. 2) As a place to collect related tickets, and capture discussions or conclusions from the community about how to proceed. -Preston -- 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.
Error in formfield in django.db.models.field
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
--
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.
