On 23/03/11 17:58, Daniel Moisset wrote:
> Trac has a way to define reports, usually it would be at /report, but
> my guess is that the django trac has it disabled.
>
> Enabling that allows an admin to define reports (even complex SQL
> queries), and/or save custom queries as canned reports. You
Hi Jacob,
I actually wrote to Adrian and he advised me to post the question on
2FA here. So I did.
Anyhow, I suppose your right. I'll take this question to Django-users
see if I can get answers there.
Thanks again for the quick reply and pointers.
Patrick
On Mar 23, 4:35 pm, Jacob Kaplan-Moss
Hi Patrick --
Look, I don't mean to be a jerk, but again this really should be
posted to django-users. Any question that begins "how can I..." or
"can Django..." isn't on-topic for this group. All of your questions
are on-topic for django-users and would probably get answers or at
least some point
Hi Jacob,
Thanks for the quick response. I appreciate the resources you pointed me to
and I will study them.
The reason I requested for help from Django-dev is because Two Factor
Authentication is a really a process. I mean, the user typically will have
to receive a token by some means whether vi
Hi Bruno,
On 03/23/2011 08:56 AM, Bruno Renié wrote:
> I'm not sure, however, how django's backwards-compatibility applies in
> this case. The widgets API has never been publicly documented but the
> official documentation encourages people to look at the code and
> create their own widgets based
On Wed, Mar 23, 2011 at 12:32 PM, Jacob Kaplan-Moss wrote:
> On Wed, Mar 23, 2011 at 4:39 AM, Luke Plant wrote:
>> It appears to me that this reports page is not nearly as useful as it
>> could be, and I'm thinking of redesigning it.
>
> Sounds just fine for me -- I really threw together the firs
Hey Patrick --
On Wed, Mar 23, 2011 at 11:42 AM, pokecho wrote:
> I am writing to ask whether it is possible to configure
> "django.contrib.auth" so that it can implement Two Factor
> Authentication to step up login security.
This question's more appropriate for django-users, which is where
usa
How could this even begin to be solved without incurring another http
request to resolve the url pattern?
The only way I can imagine it is if we had a generic /resolve/ path that
took some get parameters to return a full URL, or even it translate to a 301
redirect, but that'll get messy with PO
I am writing to ask whether it is possible to configure
"django.contrib.auth" so that it can implement Two Factor
Authentication to step up login security.
The idea is that instead authenticating against just "username" and
"password" one could add another field say "passcode" which would
receiv
On Wed, Mar 23, 2011 at 4:39 AM, Luke Plant wrote:
> It appears to me that this reports page is not nearly as useful as it
> could be, and I'm thinking of redesigning it.
Sounds just fine for me -- I really threw together the first version
with very little thought. Feel free to go ahead!
On a se
On 23 March 2011 14:26, Russell Keith-Magee wrote:
> On Wed, Mar 23, 2011 at 9:02 PM, Hanne Moa wrote:
>> Remembering the pain of going from 1.1 to 1.2 (csrf-token), is there
>> or will there be a guide/one-stop-shop for upgrading from 1.2 to 1.3?
>
> You mean -- other than the release notes [1]?
On Wed, Mar 23, 2011 at 9:02 PM, Hanne Moa wrote:
> Remembering the pain of going from 1.1 to 1.2 (csrf-token), is there
> or will there be a guide/one-stop-shop for upgrading from 1.2 to 1.3?
> That is: are there other big changes than generic view functions to
> generic view classes and could th
Remembering the pain of going from 1.1 to 1.2 (csrf-token), is there
or will there be a guide/one-stop-shop for upgrading from 1.2 to 1.3?
That is: are there other big changes than generic view functions to
generic view classes and could there be an official/canonical page
listing these?
argh-is
Hi Carl,
On Tue, Mar 15, 2011 at 6:59 AM, Carl Meyer wrote:
>
> As we've already discussed here at PyCon, I'm +1 on this change. It
> makes forms far more flexible and usable by template authors, and I
> think that will benefit almost all Django users. It's more consistent
> with Django's philoso
Congratulation !!!
Amazing, just in time for the spring
On Wed, Mar 23, 2011 at 4:52 AM, Idan Gazit wrote:
> Three cheers for the release team!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to d
On 23/03/11 10:32, Matt Harasymczuk wrote:
> I give you an example:
>
> BTW switch name from media to "useruploaded" or "uploaded", which IMHO
> is self explaining, hence MEDIA is not.
>
> STATICFILES = {
> 'uploaded' : { # old name MEDIA
> 'PREFIX' : '',
> 'ROOT': '',
> 'URL': '
I give you an example:
BTW switch name from media to "useruploaded" or "uploaded", which IMHO
is self explaining, hence MEDIA is not.
STATICFILES = {
'uploaded' : { # old name MEDIA
'PREFIX' : '',
'ROOT': '',
'URL': '',
},
'admin': {
'PREFIX' : '',
'ROOT': '',
Hi all,
Regarding http://code.djangoproject.com/wiki/Reports
It appears to me that this reports page is not nearly as useful as it
could be, and I'm thinking of redesigning it.
To me, it seems it should structured by the *role* of people who might
be involved in Django development, perhaps somet
Three cheers for the release team!
--
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...@googleg
19 matches
Mail list logo