Carl --
Thanks for the feedback!
On Feb 21, 7:47 pm, Carl Meyer wrote:
>
> It's
> important that you can get full control at some level - if a blank
> option were automatically added to ChoiceFields, how would you propose
> that a developer remove it if they didn't want it?
>
I would propose...
On Tue, Feb 21, 2012 at 10:55 PM, Thomas Woolford
wrote:
> Any files uploaded when the clone view is submitted will be uploaded on
> save and associated with the new object anyway.
>
It is perfectly valid for two DB rows to point at the same file because as
> soon as that file is re-uploaded it cr
On 22/02/2012, at 11:01 AM, Daryl wrote:
> Hi All,
>
> When running tests I often end up crashing things and when restarting
> the tests i get the line;
>
> Creating test database for alias 'default'...
> Got an error creating the test database: (1007, "Can't create database
> 'test_x'; dat
Hi All,
When running tests I often end up crashing things and when restarting
the tests i get the line;
Creating test database for alias 'default'...
Got an error creating the test database: (1007, "Can't create database
'test_x'; database exists")
Type 'yes' if you would like to try deleting
Hi Stuart,
On 02/21/2012 05:29 PM, Stuart Laughlin wrote:
> It seems to me there is a discrepancy between ModelForm and Form when
> it comes to fields with choices. When I create a ModelForm from a
> model having a CharField with choices set, the resultant form contains
> a select with a blank cho
Greetings Everyone --
It seems to me there is a discrepancy between ModelForm and Form when
it comes to fields with choices. When I create a ModelForm from a
model having a CharField with choices set, the resultant form contains
a select with a blank choice included by default. On the other hand,
Why would file uploads not work?
If the file has already been uploaded on the previous object, it will
appear in the clone view.
Any files uploaded when the clone view is submitted will be uploaded on
save and associated with the new object anyway.
It is perfectly valid for two DB rows to point
> In short, the first patch add a bullet point in the CSRF error page
> which states that this
> error can be triggered by disabled cookies.
I committed this change.
> The second patch fixes the middleware itself to make the page show the
> correct error message if the
> error is caused by disabl
Hi,
I'm working on a patch for #13223 [1], but I need some help on how to
proceed. The solution I would like to work on is to replace the "save as
new" button for a "clone object" link. This is how I understood the
suggest on the ticket, and the way makes more sense to me.
I've started to create
Cause ``reset --hard`` only resets managed files, not unmanaged files.
``git clean -fdx`` would have done the job (make sure to read the help
before issuing that command).
Cheers,
Florian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
T
Thanks, Carl. To fix this issue, I had to delete my local git clone of
the django repo, and then clone the github mirror again before
reinstalling. I thought it was due to the /build in the repo, but for
some reason a ``reset --hard`` didn't even fix it, so I'm not sure how
a rm -r then re-cloning
On Tue, Feb 21, 2012 at 12:46 PM, Carl Meyer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Ramiro,
>
> [...]
>
> It seems to me you may have mis-read Tom's message. It seems perfectly
> on-topic to me; he's not asking how to fix his problem, he's asking
> about the design of Base
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ramiro,
On 02/21/2012 08:05 AM, Ramiro Morales wrote:
> On Tue, Feb 21, 2012 at 2:58 AM, Tom wrote:
>> Hi everyone,
>
> Please start threads like this to the django-users mailing list
> as this list is dedicated exclusively to discussions about
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tom,
On 02/20/2012 10:58 PM, Tom wrote:
> I have a ModelForm and a ModelFormSet. I initialize my ModelFormSet with
> a queryset containing objects from a custom manager that is not the
> model's default manager. My formset does not validate, becaus
On Tue, Feb 21, 2012 at 2:58 AM, Tom wrote:
> Hi everyone,
Please start threads like this to the django-users mailing list
as this list is dedicated exclusively to discussions about
development of Django.
--
Ramiro Morales
--
You received this message because you are subscribed to the Google
Not to harp on about this, but I never understood not supporting multi-
line tags, in particular if it doesn't affect performance and really
is as straightforward as suggested by the OP.
Yes, they are only useful in a limited set of cases (albeit "rare" may
be overstating it), but so are multi-lin
Hi everyone,
I have a ModelForm and a ModelFormSet. I initialize my ModelFormSet with a
queryset containing objects from a custom manager that is not the model's
default manager. My formset does not validate, because ModelForms with
instances that are objects in my queryset but not in the model
On Feb 21, 12:02 pm, Aymeric Augustin
wrote:
> os.environ['TZ'] controls the ouptut of functions such as
> datetime.fromtimestamp().
>
> If you're running with USE_TZ = True, you should use the UTC versions, e.g.
> datetime.utcfromtimestamp() in your own code. However, you may be relying on
> t
Thank you all for your replies. My search on the topic had missed
most
of the past discussion, which I'm now catching up on.
Carl Meyer wrote:
> > @method_decorator(permission_required, 'thing.change_thing')
>
> Is this really any better than
> @method_decorator(permission_required("thing.change_
On 21 févr. 2012, at 10:49, Anssi Kääriäinen wrote:
>>> I can't see any point why the time zone for the process
>>> should be something else? What is gained by that? Isn't using Europe/
>>> Helsinki for the process timezone downright dangerous due to daylight
>>> saving times? Am I missing somethi
On Feb 21, 10:57 am, Danny Adair wrote:
> The question was if TIME_ZONE is not UTC then whose "today" should it
> be? And in that case I just find the user's "today" more logical than
> the server's.
My point is that it should always be UTC. When you insert a date into
the database, it will appea
On 21 févr. 2012, at 08:49, Anssi Kääriäinen wrote:
> Some information about how hard this is can be gotten by updating the
> tutorial part I to correctly use timezone aware datetimes.
This is a good point and I will ensure that the tutorial works properly
(there's a ticket about that).
However
On Tue, Feb 21, 2012 at 21:00, Anssi Kääriäinen wrote:
>[...]
> The real problem is, as said before, that whatever you do, last edited
> date doesn't work in multi-timezone setting. Somebody is going to see
> last edited "tomorrow" or seeing his last edit as "yesterday".
I agree, "last edited" as
On Feb 21, 2:33 am, Danny Adair wrote:
> On Tue, Feb 21, 2012 at 13:17, Yo-Yo Ma wrote:
> > I haven't quite read up on all the UTC-related stuff in Django as of
> > yet (couldn't find much info about it), but I found some of the posts
> > above concerning. It would seem that if a DateTimeField sh
24 matches
Mail list logo
