There is a six years old issue which has a working patch:
https://code.djangoproject.com/ticket/10827
If a migration deletes and recreates content-types, then the automatically
called create_migrations()
can result in ForeignKey constraint errors.
Example:
If Permission "Can add group" had pr
I think this is a bit of a misnomer - if we include a jQuery without IE8
support we will start dropping IE8 from the CSS, our own custom javascript,
new jquery features, community plugins will drop it etc etc. For 1.9 itself
it may simply be a case of swapping in a different jQuery version, but it
Hi Thomas, As indicated by the flags on the ticket, it "Needs tests" in
order to be committed.
On Thursday, August 20, 2015 at 5:31:46 AM UTC-4, guettli wrote:
>
> There is a six years old issue which has a working patch:
>
> https://code.djangoproject.com/ticket/10827
>
> If a migration deletes
Hi,
I think the setting is worth it, it can be really useful when working
with complex translation setups.
However, I feel that LOCALE_FILENAMES is a poor choice for the setting
name, as it differs from standard gettext terminology in a very unclear
way. Why not name it LOCALE_DOMAINS?
(To me, _F
I wrote simple test for django before, but this is not easy. But maybe I am
able do it, if I get some help.
The test would need to do the following:
1. Create a simple Model via migrations
2. implicit: ContentTypes and Permissions get created automatically.
3. Run migrations again.
4. This time
The only reason that I'm on the fence about not actively ending IE8 support
right now is that it will still be in support for the release of Django
1.9. It'll only be a month, but it's something. I'd feel more comfortable
about a soft deprecation now and a harder end for Django 1.10. It'll at
l
Could we give users guidance on overriding the admin's application specific
static files with global static files if we do this?
Not immediately clear to me what order static files are copied in, but
presumably it's possible to ensure that the jquery static files included in
the admin app direc
What about the idea to add interface to specify paths with special class or
callable?
On Wednesday, August 19, 2015 at 10:49:07 AM UTC+3, Josh Smeaton wrote:
>
> If I finish the patch in time (I think I have about a month left), then
> it'll be included in 1.9. Review and comments on the PR wil
2015-08-20 16:14 GMT+02:00 Tom Christie :
> Could we give users guidance on overriding the admin's application
> specific static files with global static files if we do this?
>
The general rule is: if several applications provide the same resource, the
earliest application in INSTALLED_APPS wins.
Le mardi 18 août 2015 01:36:28 UTC+2, Tim Graham a écrit :
>
> I think the general idea is captured in ticket #5929 -- Allow Fields to
> use multiple db columns (complex datatypes). Is that the gist of your
> proposal?
>
Thank you for this link! It seems to discuss the same end result as what
I think you should aim for a lower level test which calls
create_permissions() and update_contenttypes() in the order described in
the ticket description. This problem precedes migrations, so I don't think
there's a need to have that additional complexity in the test. Feel free to
continue the
Have a look at [1] it is a composite field implementation.
[1]
https://groups.google.com/forum/m/#!msg/django-developers/MZUcOE6-7GY/sZkBaHvC8wgJ
[2]
https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst
[3]
https://github.com/django/deps/blob/master/draft/0192-standalone-comp
To be clear: jQuery 1.x and 2.x are the exact same except for IE < 9
compatibility. jQuery v1.11.3 and v2.1.4, released simultaneously, _are_
the latest version of jQuery. It's not like "1.11.x" is an "old" release
series. 1.x and 2.x have the exact same features and API and are 100%
compatible
Thanks everyone for feedback. I think it's a good idea to send this to the
technical board to reach a consensus. Here is the summary as I see it:
Benefits of jQuery 2:
* Smaller file size (36KB or 11KB for minified version)
* "Faster" -- not sure this has any practical benefit currently, but migh
In my opinion, the question to ask when wondering if a configuration should
be a setting or not is: is this setting supposed to be changed for
different installations. In this case, I would answer no. So I think this
is more an application configuration thing which could be appropriate in an
Ap
In my experience the "easy pickings" flag is ill-defined and insufficient
for describing the difficulty of a ticket. I don't want to get stuck in
categorizing tickets just for the sake of it, but I think a drop down with
options like the following could be useful in helping contributors find
su
I never liked the "easy pickings" flag either. Your proposed change would
be a good way to identify the technical ability required to make the
changes to Django. Should we have a separate drop down with options to
identify the non-technical (bikeshedding) difficulty of the ticket? There
are certain
Most expressions already support strings, and most that support strings
expect them to be field_paths that can be wrapped in F() expressions. So
you have two options really, without built in support from other
expressions.
1. P.field.other.some_field() returns an F()
2. P.field.other.some_field
18 matches
Mail list logo
