Re: Rendering model attributes names translated by gettext() that contain non-ascii chars crash django admin?

We need a sample project or a test for Django's test suite that reproduces the issue. Generally, "is it a bug?" questions are more appropriate for django-users. After directing your query there, you can create a Trac ticket if others confirm it's a bug in Django and not in your own project. On

Re: Unicode normalization for username field

Here is one: https://groups.google.com/d/topic/django-developers/6aAHgP5g0lA/discussion (all I did was search "unicode username") Here's a relevant Trac ticket: https://code.djangoproject.com/ticket/21379 On Thursday, April 21, 2016 at 11:22:54 AM UTC-4, Rick Leir wrote: > > Hi all, > We have di

Re: [GSoC 2016] Please Critique (Condition API - Related to Auth)

Hi Connor, Unfortunately we didn't have anyone sufficiently intrigued by your ideas who wanted to mentor it. In case you'd like to try again next year, I'd suggest to get involved in the project and start submitting patches as you're able. Mentors are more wiling to invest their time to help so

Test projects needed for removal of Field.get_db_prep_lookup()/get_prep_lookup()

Claude and I have been working on a ticket [0] to remove the Field.get_db_prep_lookup() and Field.get_prep_lookup() methods in favor of moving that functionality to the lookups themselves. It would be helpful if we had some test apps and/or projects that implement these methods so we can determ

Fellow Report - April 23, 2016

Triaged --- https://code.djangoproject.com/ticket/23356 - Unable to create template tag which behaves similar to {% verbatim %} (accepted) https://code.djangoproject.com/ticket/26514 - User.refresh_from_db() does not clear Permission cache (fixed) https://code.djangoproject.com/ticket/2

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

It seems there was request.body checking in previous iterations of the PR but it was dropped for reasons that aren't entirely clear to me: https://github.com/django/django/pull/3852#discussion_r35350372 On Wednesday, April 20, 2016 at 9:30:48 PM UTC-4, Cristiano Coelho wrote: > > Hi, > > In parti

Re: #26481 - Add a "strict mode" for defer()/only()

I guess there's some question about whether or not we need to make changes in Django given Anssi's comment, "Overriding Model.refresh_from_db() allows raising failure when deferred field is accessed - is this enough for you use case?" On Friday, April 22, 2016 at 7:07:07 AM UTC-4, Fabien SCHWOB

Re: IntegrityError when cascading delete, and there post_delete that creates a new object.

Hi, sorry but this mailing list isn't a second level support channel if you don't get a question answered on django-users. On Tuesday, April 26, 2016 at 1:14:30 PM UTC-4, Paulo Maciel wrote: > > Hi, I have a problem that already published in Django users, but did not > find the solution to this.

Re: One Click Django Installer

This mailing list is about the development of Django itself. The django-users mailing list would be more appropriate for a message like this. On Sunday, April 24, 2016 at 11:53:19 AM UTC-4, Ankit Kumar wrote: > > Check this video : > > > https://www.youtube.com/watch?v=85P3Qn9Sccs >

Re: NumericListfilter or similar

Does it need to be in Django itself? I'd think probably not, at least to start, but if there's something prohibiting that, then let us know. On Tuesday, April 19, 2016 at 1:19:02 PM UTC-4, John Griebel wrote: > > I agree that we need a replacement; the current behaviour isn't all that > useful,

Re: Usage of DjangoRuntimeWarning

I think warnings.filterwarnings(RuntimeWarning, module="django..") might allow filtering without a subclass? According to the ticket, Carl offered the version of the patch with DjangoRuntimeWarning "following design discussion with Russell K-M, Malcolm T, Jannis L, and Jeremy Dunck." (in case a

Re: is_authenticated as property

ors.append( +checks.Error('%s.is_authenticated must be a property.' % cls) +) return errors On Thursday, April 28, 2016 at 10:25:01 AM UTC-4, Shai Berger wrote: > > On Monday 11 April 2016 20:13:02 Florian Apolloner wrote: > > On Monday, April 11, 2016

Re: No access to the login page to the already logged-in user through url

Django 1.10 adds a "redirect_authenticated_user" parameter for the login view which, if I understand correctly, accomplishes what you want. https://docs.djangoproject.com/en/dev/topics/auth/default/#django.contrib.auth.views.login On Friday, April 29, 2016 at 4:40:37 PM UTC-4, rajat vijay wrote:

Fellow Report - April 30, 2016

Triaged --- https://code.djangoproject.com/ticket/26537 - BaseInlineFormSet Adds N Entries to form._meta.fields For FK (duplicate) https://code.djangoproject.com/ticket/26541 - Add a DatabaseFeatures.supports_transactions() method for MySQL (accepted) https://code.djangoproject.com/tick

[ANNOUNCE] Django bugfix releases issued: 1.9.6 and 1.8.13

Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2016/may/02/bugfix-releases/ -- You received this message because you are subscribed to the Google Groups "Django developers (Contributio

Re: Django Integration

there's not really much in core itself that needs changing, more > about addition and tweaking some imports. > > Andrew > > On Sat, Mar 5, 2016 at 4:44 PM, Tim Graham > wrote: > >> Hi Andrew, >> >> What's your thinking about whether or not any of

Re: upgrade from 1.4 to 1.8

I don't recall any similar reports. Anyway, "is it a bug?" questions go to django-users. You'll need to include steps to reproduce the issue in order to get help. On Wednesday, May 4, 2016 at 7:29:52 AM UTC-4, Samarjeet Singh wrote: > > the problem is on the flush function of django 1.8 and beca

Re: failure to load fixtures during unit tests

Hi Rich, django-users is the appropriate place to ask "is it a bug?" type questions. We try not to use this mailing list as a second level support channel, otherwise it'd get really noisy. Thanks for understanding. By the way, Django 1.7 is no longer supported. Please make sure you can reproduc

Re: re-thinking middleware

I've been working on this and wanted to raise a couple points for discussion. How should we treat error messages in place like system checks where we have phrases like "Edit your MIDDLEWARE_CLASSES" ... of course the check can easily check both MIDDLEWARE and MIDDLEWARE_CLASSES without much eff

Re: Django Integration

The future is hard to predict, but I'll add that I'm a tad nervous about this as well. I'm completely inexperienced with channels at this time. Who else has a good grasp of the code right now and could help fix release blocking bugs if Andrew isn't available? Are we playing for any or all bug f

Re: re-thinking middleware

LEWARE using test class and not the other way > > around as it will make the MIDDLEWARE_CLASSES code removal clearer. > > > > Simon > > > > Le mercredi 4 mai 2016 19:59:05 UTC-4, Tim Graham a écrit : > > > > I've been working on this and

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

ps://github.com/django/django/pull/6447 On Tuesday, April 26, 2016 at 6:47:09 PM UTC-4, Tim Graham wrote: > > It seems there was request.body checking in previous iterations of the PR > but it was dropped for reasons that aren't entirely clear to me: > https://github.com/django/djang

Fellow Report - May 7, 2016

Triaged --- https://code.djangoproject.com/ticket/26555 - makemigrations serializer isinstance() check fails for subclasses of Decimal (and DateTime etc) (accepted) https://code.djangoproject.com/ticket/26568 - in_bulk when run on a query set should not need a list of IDs (duplicate) h

Re: Unicode normalization for username field

Rather than change the behavior of Python 2 near its last supported version of Django, I would make the default validator ASCII on Python 2 and Unicode on Python 3. On Tuesday, May 3, 2016 at 9:29:06 AM UTC-4, Rick Leir wrote: > > Hi all > Could there be a consensus with > -default to ASCII > -o

Re: Template-based widget rendering

I've been working on testing and writing documentation for Preston's PR: https://github.com/django/django/pull/6498 About backwards compatibility, the current implementation which seems to be based on Carl's proposal requires either a) 'django.forms' in INSTALLED_APPS (so the APP_DIRS loader ca

Re: Django Integration

I'm not convinced either way about whether putting this in core will help mature it and fix bugs more quickly or not. I don't have any sense of how the code might change after we merge it, but things get more complicated if we start selectively backporting somes fixes for Django's monthly bug fi

graphics artist (e.g. OmniGraffle) needed for updated middleware graphic

Would someone like to help update the graphic in this section [0] for the new-style middleware implemented in PR#6501 [1]. I'm not quite sure what the updated graphic will look like yet, but there isn't any use thinking about that if we don't have someone to do the work. :-) The existing image

Re: Template-based widget rendering

About the fallback engines, the main use case I have in mind (as Claude alluded to) is if you want to use django.forms "standalone" without the rest of Django. In that case, it seems like it would be nice not to require someone to configure settings.TEMPLATES. Here's an alternate proposal: Crea

Re: URL dispatching framework: feedback requested

I'm not targeting this for 1.10. The patch hasn't been under review and is likely too much to review in a couple days. Also documentation remains outstanding. On Wednesday, May 11, 2016 at 12:52:33 PM UTC-4, Asif Saifuddin wrote: > > Can we expect this to be merged on 1.10 alpha? after that the

Re: Template-based widget rendering

> Hi Tim, > > On 05/10/2016 07:10 AM, Tim Graham wrote: > > About the fallback engines, the main use case I have in mind (as Claude > > alluded to) is if you want to use django.forms "standalone" without the > > rest of Django. In that case, it seems li

Re: Template-based widget rendering

gt; > On 05/11/2016 11:30 AM, Tim Graham wrote: > >> What's your proposal for changing the default TEMPLATES? Using Jinja2 > or > >> DTL? > > > > At some point maybe we can adopt Jinja2 as a required dependency. Until > > then, the default startprojec

Re: Unicode normalization for username field

06 UTC+2, Tim Graham a écrit : >> >> Rather than change the behavior of Python 2 near its last supported >> version of Django, I would make the default validator ASCII on Python 2 and >> Unicode on Python 3. >> > > I can buy this, providing we don't face mi

Re: Admin Themes in 1.10

Seems okay to me. On Sunday, May 8, 2016 at 11:19:43 AM UTC-4, David Sanders wrote: > > Ever since PR #5567 [1] (which is great, yay CSP) I've been concerned > about the impact it will invariably have on admin themes going forward. By > removing any inline JS, the various admin JS functionality

Re: Template-based widget rendering

pgrade warning to detect this situation ('django.contrib.admin' in INSTALLED_APPS but not 'django.forms') and advise the user to add 'django.forms' to INSTALLED_APPS. Thoughts? On Thursday, May 12, 2016 at 1:17:23 PM UTC-4, Carl Meyer wrote: > > On 05/12/2016 0

Fellow Report - May 14, 2016

Triaged --- https://code.djangoproject.com/ticket/26611 - Make "Share this traceback on a public Web site" feature on debug page optional (duplicate) https://code.djangoproject.com/ticket/26606 - 'string_if_invalid' option does not work with custom filter (invalid) https://code.djangopr

status of 1.10 release blockers

Time to kickoff the progress tracker for the next major release! At this time, I'm considering master feature frozen besides the tickets marked "ready for checkin" [1] and those tagged "1.10" [2]. Let me know if I missed anything critical. I'll continue working with the ticket owners to polish

Re: Template-based widget rendering

Carl, there are other widgets such as admin/widgets/related_widget_wrapper.html which include the built-in widget templates. It's actually a variable include, {% include widget.template_name %}, so copying the included template isn't feasible in this case. Claude, I'm not quite sure what the i

Re: Template-based widget rendering

me: > > TEMPLATES = { > { > 'BACKEND': 'django.template.backends.django.DjangoTemplates', > 'DIRS': [], > 'APP_DIRS': True, > 'OPTIONS': { > 'loaders': [ > 'django.forms.tem

Re: status of 1.10 release blockers

y. On Saturday, May 14, 2016 at 7:40:32 PM UTC-4, Tim Graham wrote: > > Time to kickoff the progress tracker for the next major release! > > At this time, I'm considering master feature frozen besides the tickets > marked "ready for checkin" [1] and those tagged &q

Re: Organizing the built-in system check framework's hint messages

The security checks errors are defined as module level constants to avoid some redundancy since these can be imported in tests: https://github.com/django/django/blob/0eac5535f7afd2295b1db978dffb97d79030807e/django/core/checks/security/base.py. If you feel your approach would be an improvement, m

Re: status of 1.10 release blockers

The CSRF patch is merged. I'm a bit stuck on the middleware one, however, I don't think it's a blocker for alpha. I think I'll create the stable branch and make the release later today (in about 7 hours), unless there are objections. On Wednesday, May 18, 2016 at 10:03:17

[ANNOUNCE] Django 1.10 alpha 1 released

We've made the first release on the way to Django's next major release, Django 1.10! With two and a half months until the scheduled final release, we'll need timely testing from the community to ensure an on-time and stable release. Check out the blog post: https://www.djangoproject.com/weblog/

Re: Testing pre-release Django

I'm completely supportive of this effort. In past release cycles, I've done testing with djangoproject.com and sent some PRs to its dependencies. The blocker to upgrading is always waiting for each project to make a release with the fixes. We could provide some guidance and suggest that project

Fellow Report - May 21, 2016

Triaged --- https://code.djangoproject.com/ticket/26629 - Login failures should be logged (duplicate) https://code.djangoproject.com/ticket/26633 - OneToOneField's non-existence behaviour is inelegant (duplicate) https://code.djangoproject.com/ticket/26632 - System check for list_displ

Re: Better form fields for django.contrib.postgres.fields

A couple suggestions: It'd be better to propose each enhancement separately (and on this mailing list, rather than in Trac) rather than combining them into one ticket. It's not obvious to me that all the proposed features which mainly involve forms should be declared at the model level. I guess

Re: Rewriting admin internals

What's the "forms refactor"? On Wednesday, May 25, 2016 at 9:04:48 AM UTC-4, Asif Saifuddin wrote: > > Hi is_null, > > form refactor is an important part but that shouldn't stop us from > starting the process. > > thanks > > On Wednesday, May 25, 2016 at 3:19:36 PM UTC+6, is_null wrote: >> >> Sho

Re: Rewriting admin internals

I'm skeptical of moving anything JavaScript related from admin into core as this makes a stronger endorsement of and coupling to jQuery. On Thursday, May 26, 2016 at 10:22:31 AM UTC-4, is_null wrote: > > There are a lot of interresting things to do, perhaps we could extract > code from the admin

Re: Rewriting admin internals

I'm not sure what you mean. Are solutions like the third-party package you pointed to insufficient? On Thursday, May 26, 2016 at 2:01:50 PM UTC-4, is_null wrote: > > On Thu, May 26, 2016 at 4:37 PM, Tim Graham > wrote: > > I'm skeptical of moving anything JavaScrip

Fellow Report - May 28, 2016

Triaged --- https://code.djangoproject.com/ticket/26646 - Add IOBase methods required by TextIOWrapper to FileProxyMixin (acepted) https://code.djangoproject.com/ticket/26653 - Make syndication's lastBuildDate timezone aware (accepted) https://code.djangoproject.com/ticket/26657 - MySQL

Using "py2" Trac keyword to tag Python 2-specific issues

I've started tagging Python 2-specific Trac tickets with the "py2" keyword. You can view such issues using: https://code.djangoproject.com/query?status=!closed&keywords=~py2 Since Django 1.11 will be the last version of Django to support Python 2, my plan is to close these issues if they don't

Re: missing feature, View permission for django admin

This feature is tracked in https://code.djangoproject.com/ticket/8936. Feel free to review, contribute to, or test the patch if you want to help. On Tuesday, May 31, 2016 at 8:26:41 AM UTC-4, Ander Ustarroz wrote: > > I am surprised this feature is not implemented yet, at the moment when we > cr

Re: parent: [ 'Invalid pk "0" - object does not exist.' ]

Sorry, but this post without any explanation doesn't help much. For usage questions, please use the django-users mailing list. To report bugs, use https://code.djangoproject.com/. On Tuesday, May 31, 2016 at 8:26:41 AM UTC-4, L K Singh wrote: > > class AccountTypeSerializer(serializers.ModelSer

Re: Trac is broken

If this problem has been reported before, I don't remember it. Nothing about our Trac installation has changed recently that I'm aware of. In case it helps, I just updated to Trac 1.0.11. It's unclear if the problem would be our problem and or an issue with Trac but for what it's worth, our bug

Re: Threads and db connection handling question

Here's a ticket requesting the documentation you seek (as far as I understand): https://code.djangoproject.com/ticket/20562 On Wednesday, June 1, 2016 at 6:34:05 PM UTC-4, Cristiano Coelho wrote: > > Let me start saying sorry if this actually belongs to django-users rather > than developers. > >

Re: Some thoughts on upgrade pain & deprecations.

> > Aside: I think the `.urls = ...` -> `@override_settings(ROOT_URLCONF=...)` > change to test cases is missing from those notes? > The 1.10 release notes say, "SimpleTestCase.urls is removed." > I expected to have seen a deprecation warning when running the tests under > 1.9, although was

[ANNOUNCE] Django bugfix release issued: 1.9.7

Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2016/jun/04/bugfix-release/ -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop

Fellow Report - June 4, 2016

Triaged --- https://code.djangoproject.com/ticket/26680 - more than one row returned by a subquery used as an expression (duplicate) https://code.djangoproject.com/ticket/23518 - Subquery does not respect explicit __exact (fixed) https://code.djangoproject.com/ticket/26681 - save_as=Tru

Re: Official Projects DEP

Hi Andrew, Here's my 2 cents: 1. It might be nice if projects had more than one shepherd so there's not a single point of failure. Of course, if all members of the maintenance team end up joining the team, then there's no issue. 2. Re: "The main project documentation does not have to be

Fellow Report - June 11, 2016

Triaged --- https://code.djangoproject.com/ticket/26718 - add system check for existence of the fields specified by ForeignKey.to_field (accepted) https://code.djangoproject.com/ticket/26717 - Allow customizing stream attribute of Serializer for custom serializers (accepted) https://cod

Re: missing feature, View permission for django admin

can do. > > I'm really looking forward for this feature, and judging from the > frequency this topic is raised on the ml, I'm not the only one ;) > > Thanks a lot, > > Olivier > > > > On 31 May 2016 13:20, "Tim Graham" > > wrote: > >

Re: pass entire request object to urlresolver

I believe that's implemented as part of Marten's URL dispatcher work: https://github.com/django/django/pull/5578. On Tuesday, June 14, 2016 at 8:20:59 AM UTC-4, Elephant Liu wrote: > > Hi all, I'd like to introduce a new feature to django urlresolver. > > Currently, django urlresolver can only ha

Binding LiveServerTestCase bind to port 0

In IRC the other day, Donald pointed out https://www.dnorth.net/2012/03/17/the-port-0-trick/ and suggested that Django might be able to take advantage of that technique. I put together a proof of concept that seems to work: https://github.com/django/django/pull/6791 I'm wondering if anyone see

Re: status of 1.10 release blockers

There are a few small issues to finish up, but if all goes well, the beta release will happen sometime tomorrow (at least 24 hours from now). On Thursday, May 19, 2016 at 2:08:59 PM UTC-4, Tim Graham wrote: > > The CSRF patch is merged. I'm a bit stuck on the middleware one, however,

Re: status of 1.10 release blockers

I'm postponing the release until next week as some release blockers remain: https://code.djangoproject.com/query?status=!closed&severity=Release%20blocker On Friday, June 17, 2016 at 5:33:04 PM UTC-4, Claude Paroz wrote: > > Le vendredi 17 juin 2016 16:52:50 UTC+2, Tim

Fellow Report - June 18, 2016

Triaged --- https://code.djangoproject.com/ticket/26751 - Make dbshell exit with the shell's error code (accepted) https://code.djangoproject.com/ticket/26752 - RenameModel requires camel case model names (duplicate) https://code.djangoproject.com/ticket/26755 - test_middleware_classes

Re: decorator_from_middleware changes

I may have seen this idea in IRC but instead of a new middleware_decorator function did you consider varying decorator_from_middleware's behavior based on "if settings.MIDDLEWARE is None" similar to what BaseHandler does? We could add a check in decorator_from_middleware to raise an error if MI

Re: status of 1.10 release blockers

the other two issues. On Saturday, June 18, 2016 at 8:05:32 PM UTC-4, Tim Graham wrote: > > I'm postponing the release until next week as some release blockers remain: > > > https://code.djangoproject.com/query?status=!closed&severity=Release%20blocker > > On Friday

Re: Fate of sql* management commands

Marcin, what are you hoping to accomplish with your latest mail? As Aymeric said in another thread, repeated complaining is not going to help. There's already an accepted ticket for this feature. If you want to be productive and helpful, pick up Andrew's patch and try to complete it. Alternative

Re: Fate of sql* management commands

4, Marcin Nowak wrote: > > > > On Tuesday, June 21, 2016 at 3:28:26 PM UTC+2, Tim Graham wrote: >> >> Marcin, what are you hoping to accomplish with your latest mail? As >> Aymeric said in another thread, repeated complaining is not going to help. >> > > S

Re: Binding LiveServerTestCase bind to port 0

uppose we could deprecate DJANGO_LIVE_TEST_SERVER_ADDRESS and use a > LiveServerTestCase.server_thread_class = LiveServerThread attribute to > create the thread and suggest overriding it in the deprecation warning > message if new behavior is problematic. > > Simon > > Le jeudi 16 juin 2016 21:23

Re: status of 1.10 release blockers

The blocker is merged so I'll release the beta in a couple hours if no one stops me. On Monday, June 20, 2016 at 9:10:12 PM UTC-4, Tim Graham wrote: > > The remaining blocker: > > UserCreationForm doesn't call normalize_email and normalize_username > https://code.djang

Re: Fate of sql* management commands

Django. If you continue down that path, I guess all we can do is ignore you because we don't like to work with people who can't be polite. On Tuesday, June 21, 2016 at 4:55:13 PM UTC-4, Marcin Nowak wrote: > > > > On Tuesday, June 21, 2016 at 5:49:08 PM UTC+2, Marcin Nowak wrote:

[ANNOUNCE] Django 1.10 beta 1 released

We've made the second release on the way to Django's next major release, Django 1.10! With a month and a half until the scheduled final release, we'll need timely testing from the community to ensure an on-time and stable release. Check out the blog post: https://www.djangoproject.com/weblog/20

Re: Adding a database-agnostic JSONField into Django

Making JSONField a core field was discussed in https://groups.google.com/d/topic/django-developers/sAgYOqBUvgI/discussion Adam said, "my recent completion of its *JSONField* for MySQL 5.7+ is very similar to the *contrib.postgres* one, copying and adapting large parts of code from Marc Tamlyn's

change commit message format to present tense?

A few contributors indicated in #django-dev that it could be beneficial to change our commit message format to match git's guidelines of present tense (instead of our current past tense convention) as it would be one less thing to remember when contributing to Django. Besides consistency with th

Re: change commit message format to present tense?

With the idea of saving characters in the first line, would "Fix #XXX: Message" be better than ""Fix #XXX -- Message" also? This saves two characters without any loss of readability as far as I see. On Friday, June 24, 2016 at 4:44:10 PM UTC-4, Aymeric Augustin wrote: > > > On 24 Jun 2016, at 20

Re: change commit message format to present tense?

Reinout, I agree that the imperative mood seems awkward, especially when reading history, but of course I'm influenced by my experience with Django's history. No doubt others find it more natural. I guess if I had my way, we would keep using past tense, although I will say that it gets a bit ti

Re: Django Model Fields a repr_output property, to include a field in the string representation of an object

A new model field option doesn't seem necessary. I think a cleaner solution would be something like a decorator that takes a list of fields, e.g. @repr_fields('first_name', 'last_name') class Person(...): ... This doesn't need to live in Django itself though. On Thursday, June 23, 2016 at

Re: Google Summer of Code Updates - Class based indexes

Support for more index types is planned. This is only part 1 of the work. Please see https://gist.github.com/akki/7fd50505928dac58dc350e6cb186a404 for the timeline. On Monday, June 27, 2016 at 5:02:06 PM UTC-4, thinkwel...@gmail.com wrote: > > Will it be possible to create indexes other than btr

Re: Future of the development server's auto-reloading

A pull request is proposed to add a new setting to allow specifying a custom reloader: https://github.com/django/django/pull/6719 Is this something anyone else would find useful and does it seems like we could continue support that option even if autoreloading is refactored based on the ideas

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

might be useful for documenting best practices as other apps run into similar troubles. https://code.djangoproject.com/ticket/26810 On Saturday, May 7, 2016 at 10:57:55 AM UTC-4, Tim Graham wrote: > > After discussion on the PR, we concluded that the reasons that the > request.body check

Re: Django Model Fields a repr_output property, to include a field in the string representation of an object

Friedland > www.bugben.com > > On Monday, June 27, 2016 at 6:24:57 AM UTC-7, Tim Graham wrote: >> >> A new model field option doesn't seem necessary. I think a cleaner >> solution would be something like a decorator that takes a list of fields, >> e.g. >

Re: Form field labels change proposal

How would projects opt-in to the new behavior and silence the deprecation warning? On Saturday, July 2, 2016 at 8:04:23 AM UTC-4, Sergei Maertens wrote: > > So, this is the follow up from the discussion with Markus. > > Implementation wise, we would only apply the capfirst on ModelForm fields >

Fellow Report - July 2, 2016

Triaged --- https://code.djangoproject.com/ticket/26807 - Document how to replicate SubfieldBase behavior of calling to_python on assignment (accepted) https://code.djangoproject.com/ticket/26813 - ModelForm RadioSelect widget for foreign keys should not present a blank option if blank=F

Fellow Report - June 25, 2016

(I neglected to post this last week.) Triaged --- https://code.djangoproject.com/ticket/26779 - i18n_javascript should take extra_context as argument (accepted) https://code.djangoproject.com/ticket/26781 - SQLite crashes when changing the case of db_table (accepted) https://code.djan

Trac spam attack / spam filter reactivated

In the past couple hours, code.djangoproject.com experienced a spam attack of new tickets and wiki pages. After running without the spam filter for at least a couple months (I forget exactly when I deactivated it but it was sometime after we switched to requiring authenticated users to file a t

Re: is the desired implementation -->https://code.djangoproject.com/ticket/25912#comment:10

Hi, you're more likely to inspire a good discussion if you summarize the discussion on the ticket and offer your own opinion on the matter. On Saturday, July 9, 2016 at 10:31:33 AM UTC-4, Sarabia Cobo Belén wrote: > > Hello everyone, > > I create this thread to know if it is desired ticket 2591

Fellow Report - July 9, 2016

Triaged --- https://code.djangoproject.com/ticket/26836 - Allow applications to register links in the admin interface (accepted) https://code.djangoproject.com/ticket/26880 - test_module_loading.py imports the imp-library which raises PendingDeprecationWarning (duplicate) https://code.d

Re: Admin-Actions also in the object details view

I haven't seen any other activity on the idea if that's what you're asking. There aren't any formal plans for Django development... the direction is steered by the patches that people contribute. On Sunday, July 10, 2016 at 6:32:47 PM UTC-4, Cristiano Coelho wrote: > > Sorry to bring this up (qu

Re: Exceptions caught by the "include" template tag make it hard to rely on tests

Found in another thread [0]: "Some time in late 2003, Adrian and I decided that errors in templates were best handled silently - the idea was that it would prevent untrained template editors from being able to 500-error a site with a typo." And another [1]: "The broad reasoning is that a parti

Re: Exceptions caught by the "include" template tag make it hard to rely on tests

e. On Monday, July 11, 2016 at 6:17:58 PM UTC-4, Shai Berger wrote: > > On Monday 11 July 2016 22:45:31 Florian Apolloner wrote: > > On Monday, July 11, 2016 at 7:56:34 PM UTC+2, Tim Graham wrote: > > > As for me as a developer, I'd support removing the exception si

Re: status of 1.10 release blockers

I'm planning for the release candidate on Monday. The one blocker is #26888 <https://code.djangoproject.com/ticket/26888> - RegexURLResolver doesn't work in threaded environments. On Tuesday, June 21, 2016 at 4:29:47 PM UTC-4, Tim Graham wrote: > > The blocker is merged so

Re: change commit message format to present tense?

As it seems there isn't consensus on this and the current message format works fine as far as I'm concerned, I'm dropping the proposal. I thought the question "if we adopt some new SCM tool that has a different commit message format, would we adopt that format?" is an interesting one. On Thursd

Re: SelectMultiple widget value_from_datadict enhancement suggestion

I've seen a few patches recently to move things toward duck-typing so this seems welcome. On Saturday, July 16, 2016 at 4:41:59 PM UTC-4, Marcin Nowak wrote: > > Dear all. > > I would just say that implementation of SelectMultiple.value_from_datadict > is not based on duck typing, and has some d

Fellow Report - July 16, 2016

This week I looked at all the dependencies for djangoproject.com to see how they’re doing with Django 1.10 compatibility. Mostly, it was just a matter of adding 1.10 to the tox and Travis configs. See the “ Authored” section for details. I’m running an informal sprint during the talks at Djan

[ANNOUNCE] Django security releases issued: 1.10 release candidate 1, 1.9.8, and 1.8.14

Today the Django team issued 1.10 release candidate 1, 1.9.8, and 1.8.14 as part of our security process. This releases address a security issue, and we encourage all users to upgrade as soon as possible. Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2

DjangoCon US sprints communication (IRC is blocked)

Many ports are blocked on the conference network, including 6667 for IRC. Does anyone have a preference about whether to use a slack channel or to stick with #django-sprint on IRC and recommend something like IRCCloud to bypass the firewall? Or do you have any other ideas? The sprints are on Th

Re: Translatable Site.name

If we were able to switch to declaring sites as settings rather than as models as described in https://groups.google.com/d/topic/django-developers/OGOf1TfSBBs/discussion, I believe it would be more feasible. On Tuesday, July 19, 2016 at 7:11:03 PM UTC-4, Shai Berger wrote: > > On Wednesday 20 J

Re: Middleware error framework, high level logging for database queries

For 1, I'm wondering if there's anything preventing that from being implemented as a third-party package? It seems that could be a first step toward getting a better sense of the idea and whether or not it should be included in core. For 2, a first step could be to add proper hooks in Django so

Re: Improve queries on django admin

I'm a bit wary of the complexity this would add, especially given this warning in the documentation: The defer() method (and its cousin, only() , below) are only for advanced use-cases. They provi

<    8   9   10   11   12   13   14   15   16   17   >