Re: Django Admin New Look
Le 29 juil. 2015 à 13:13, elky a écrit : > > I can create small kit which will contain only icons that used in the project > - it will allow us to save about 70KB. But the question is - how to support > this kit in future if someone decide to add new icons ? Indeed, it could be difficult to maintain in the medium term. If I remember correctly, the new theme already adds ~300kB of fonts. Saving 70kB of icons doesn't change that much. Shipping the entire set sounds easier at this point. -- Aymeric. -- 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 receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/89C4715B-4CED-469F-A5D7-2F3251CB3AD5%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
Re: Django Admin New Look
One thing that might be nice to do with the admin, especially in the context of the fonts but also with jQuery, is to give an easy override to use CDN versions of the files. Django still needs to bundle them for offline work, and the default should be to include Django's own ones, but it would be good on production sites to use CDNs (probably google, or make it configurable). It may be that this is more work than it's worth, but as some of these files, especially jQuery, font awesome and Roboto are widely used around the internet now many users would already have them cached - even if it's just from another Django admin. On 30 July 2015 at 09:55, Aymeric Augustin < aymeric.augustin.2...@polytechnique.org> wrote: > Le 29 juil. 2015 à 13:13, elky a écrit : > > > > I can create small kit which will contain only icons that used in the > project - it will allow us to save about 70KB. But the question is - how to > support this kit in future if someone decide to add new icons ? > > Indeed, it could be difficult to maintain in the medium term. > > If I remember correctly, the new theme already adds ~300kB of fonts. > Saving 70kB of icons doesn't change that much. > > Shipping the entire set sounds easier at this point. > > -- > Aymeric. > > -- > 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 receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/89C4715B-4CED-469F-A5D7-2F3251CB3AD5%40polytechnique.org > . > For more options, visit https://groups.google.com/d/optout. > -- 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 receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1E0grw%3D3MVo6i81mt%2BfmrYn7UZ9dK_FO7%3D3gXAPuSZVVA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Making max_length argument optional
> Le 29 juil. 2015 à 18:25, Podrigal, Aron a écrit : > > I see models as what defines the database ddl and and not a representation > from a end users perspective. Django models do a bit more than this: see the `validators` argument, EmailField, etc. > And I see the tight coupling between the 2 improper. I understand your perspective; it's a trade-off between purity and convenience and the optimal answer depends on each project. > For me I rarely use the builtin generated widgets, I use restframework so all > I'm interested in a model is for db definition in a highly customizable way. Please make sure your proposals also account for the various way Django can be and has been used :-) -- Aymeric. -- 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 receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2A451482-2DDD-42CE-895B-55E1FF1026D3%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
Re: Django Admin New Look
I am wary of privacy implications (leaking referers) of making it too easy to use a CDN, all the more since the admin is lightweight and not performance-critical. -- Aymeric. > Le 30 juil. 2015 à 11:05, Marc Tamlyn a écrit : > > One thing that might be nice to do with the admin, especially in the context > of the fonts but also with jQuery, is to give an easy override to use CDN > versions of the files. Django still needs to bundle them for offline work, > and the default should be to include Django's own ones, but it would be good > on production sites to use CDNs (probably google, or make it configurable). > It may be that this is more work than it's worth, but as some of these files, > especially jQuery, font awesome and Roboto are widely used around the > internet now many users would already have them cached - even if it's just > from another Django admin. > >> On 30 July 2015 at 09:55, Aymeric Augustin >> wrote: >> Le 29 juil. 2015 à 13:13, elky a écrit : >> > >> > I can create small kit which will contain only icons that used in the >> > project - it will allow us to save about 70KB. But the question is - how >> > to support this kit in future if someone decide to add new icons ? >> >> Indeed, it could be difficult to maintain in the medium term. >> >> If I remember correctly, the new theme already adds ~300kB of fonts. Saving >> 70kB of icons doesn't change that much. >> >> Shipping the entire set sounds easier at this point. >> >> -- >> Aymeric. >> >> -- >> 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 receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To post to this group, send email to django-developers@googlegroups.com. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/89C4715B-4CED-469F-A5D7-2F3251CB3AD5%40polytechnique.org. >> For more options, visit https://groups.google.com/d/optout. > > -- > 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 receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAMwjO1E0grw%3D3MVo6i81mt%2BfmrYn7UZ9dK_FO7%3D3gXAPuSZVVA%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- 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 receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/85008366-BE53-4260-A533-212BCB66F98B%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
Re: @staff_member_required handling of non-staff users
I like the behavior of showing the login screen if they don't have
permission. It's simple and pretty friendly. The new hint is helpful too.
On Tuesday, July 28, 2015 at 4:16:58 PM UTC-4, Carl Meyer wrote:
>
> On 07/28/2015 12:36 PM, Tim Graham wrote:
> > We received a ticket [1] noting that when a non-staff user tries to
> > access an admin page, they will be redirected to the admin login page
> > with no explanation. A pull request [2] proposes to add this message to
> > login page if a user is authenticated, "While you are authenticated as
> > {{ username }}, you are unfortunately not authorized to access this page
> > -- would you care to re-login?" -- the thinking being that any
> > authenticated user viewing the login page will have reached it via such
> > a redirect. (Logged in staff users cannot view the login page because
> > they are redirected back to the admin index page if they try to access
> it).
>
> This solution seems reasonable to me.
>
> > I think it's a bit odd for the @staff_member_required to redirect
> > non-staff users to the login page (which is a side effect of using the
> > user_passes_test() function) as if many users have two separate "staff"
> > and "non-staff" accounts.
>
> I think that probably varies quite a bit by project. There are certainly
> projects (especially on staging sites where a lot of testing occurs that
> sometimes requires multiple accounts) where I do have multiple accounts,
> one staff and others not, and I've used the re-login ability.
>
> > Instead I propose to raise PermissionDenied so
> > that developers can use handler403 to customize the behavior.
>
> I guess this should be somewhat practical now that we have
>
> https://github.com/django/django/commit/70779d9c1cab77791c73b72e8a63f60184d8f2b0
>
> -- without that it would be hard to distinguish one type of 403 from
> another.
>
> It feels a bit ugly to me in the cases where you want to return
> something other than a 403 (e.g. the 302 that is returned currently)
> that you'd have to do that via `handler403`. And you'd still have the
> `got_request_exception` signal sent, even though you are choosing to
> handle it in a non-exceptional fashion.
>
> > What are your thoughts on this issue?
>
> I think the proposed PR for a UX hint is a good improvement on the
> status quo, regardless.
>
> In theory I like the idea of being able to customize what happens when a
> `staff_member_required` check fails. For that matter, I'd like it if
> `user_passes_test` itself were more customizable, so it could be
> configured to return either a redirect, a 403, or a 404.
>
> I am not convinced that `handler403` is the right place to do this
> customization. To me that seems like the place to customize your 403
> responses, not to make policy decisions that may result in returning
> something that isn't a 403 at all.
>
> The obvious place for this type of customization to happen is in an
> optional parameter to `@staff_member_required`. The problem in the admin
> is that the decorator is applied internally, not by the developer.
> Perhaps an `AdminSite` attribute?
>
> Carl
>
> > [1] https://code.djangoproject.com/ticket/25163
> > [2] https://github.com/django/django/pull/5044
>
>
--
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 receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/84d74c82-3328-478f-8210-c5be481a5be8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: @staff_member_required handling of non-staff users
+1
Sent from my iPad
> On Jul 30, 2015, at 6:19 AM, Collin Anderson wrote:
>
> I like the behavior of showing the login screen if they don't have
> permission. It's simple and pretty friendly. The new hint is helpful too.
>
>> On Tuesday, July 28, 2015 at 4:16:58 PM UTC-4, Carl Meyer wrote:
>> On 07/28/2015 12:36 PM, Tim Graham wrote:
>> > We received a ticket [1] noting that when a non-staff user tries to
>> > access an admin page, they will be redirected to the admin login page
>> > with no explanation. A pull request [2] proposes to add this message to
>> > login page if a user is authenticated, "While you are authenticated as
>> > {{ username }}, you are unfortunately not authorized to access this page
>> > -- would you care to re-login?" -- the thinking being that any
>> > authenticated user viewing the login page will have reached it via such
>> > a redirect. (Logged in staff users cannot view the login page because
>> > they are redirected back to the admin index page if they try to access
>> > it).
>>
>> This solution seems reasonable to me.
>>
>> > I think it's a bit odd for the @staff_member_required to redirect
>> > non-staff users to the login page (which is a side effect of using the
>> > user_passes_test() function) as if many users have two separate "staff"
>> > and "non-staff" accounts.
>>
>> I think that probably varies quite a bit by project. There are certainly
>> projects (especially on staging sites where a lot of testing occurs that
>> sometimes requires multiple accounts) where I do have multiple accounts,
>> one staff and others not, and I've used the re-login ability.
>>
>> > Instead I propose to raise PermissionDenied so
>> > that developers can use handler403 to customize the behavior.
>>
>> I guess this should be somewhat practical now that we have
>> https://github.com/django/django/commit/70779d9c1cab77791c73b72e8a63f60184d8f2b0
>>
>> -- without that it would be hard to distinguish one type of 403 from
>> another.
>>
>> It feels a bit ugly to me in the cases where you want to return
>> something other than a 403 (e.g. the 302 that is returned currently)
>> that you'd have to do that via `handler403`. And you'd still have the
>> `got_request_exception` signal sent, even though you are choosing to
>> handle it in a non-exceptional fashion.
>>
>> > What are your thoughts on this issue?
>>
>> I think the proposed PR for a UX hint is a good improvement on the
>> status quo, regardless.
>>
>> In theory I like the idea of being able to customize what happens when a
>> `staff_member_required` check fails. For that matter, I'd like it if
>> `user_passes_test` itself were more customizable, so it could be
>> configured to return either a redirect, a 403, or a 404.
>>
>> I am not convinced that `handler403` is the right place to do this
>> customization. To me that seems like the place to customize your 403
>> responses, not to make policy decisions that may result in returning
>> something that isn't a 403 at all.
>>
>> The obvious place for this type of customization to happen is in an
>> optional parameter to `@staff_member_required`. The problem in the admin
>> is that the decorator is applied internally, not by the developer.
>> Perhaps an `AdminSite` attribute?
>>
>> Carl
>>
>> > [1] https://code.djangoproject.com/ticket/25163
>> > [2] https://github.com/django/django/pull/5044
>>
>
> --
> 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 receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/84d74c82-3328-478f-8210-c5be481a5be8%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
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 receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/148B0A64-B65F-43A6-8258-EFFC3F6D3660%40comcast.net.
For more options, visit https://groups.google.com/d/optout.
Django 1.8 has an undocumented change regarding template comments
I can't tell which exact release introduced this, since I went directly
from 1.7.9 to 1.8.3, but one of my templates suddenly started rendering
differently when I did.
The template had a typo with one of its {# #}-style template comments; it
was accidentally written as: {# comment here %}.
This wasn't noticeable in Django 1.7.9, though, because it would still
treat that whole line like a comment, and "comment here" would not appear
in the rendered output. But as soon as I installed Django 1.8.3, I started
seeing the entire "{# comment here %}" text in the rendered output.
Anyone know what code change triggered this altered rendering behavior?
There's no mention of changes to template comments in any of the release
notes for Django 1.8.x.
--
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 receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/685fd881-81a2-4f5c-8d91-b83c95521112%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Django 1.8 has an undocumented change regarding template comments
Hi Robert,
I don't exactly know which release introduced this change but I'd bet on
1.8.0 since a lot template related logic was refactored during its
development.
If you want to isolate the exact commit I'd suggest you try bisecting [1]
Django's source.
I think the change was unintentional but the fact that "{# foo %}" wasn't
displayed in 1.7.9 looks like a bug to me.
Simon
[1]
https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#bisecting-a-regression
Le jeudi 30 juillet 2015 21:48:16 UTC-4, Robert Rollins a écrit :
>
> I can't tell which exact release introduced this, since I went directly
> from 1.7.9 to 1.8.3, but one of my templates suddenly started rendering
> differently when I did.
>
> The template had a typo with one of its {# #}-style template comments; it
> was accidentally written as: {# comment here %}.
>
> This wasn't noticeable in Django 1.7.9, though, because it would still
> treat that whole line like a comment, and "comment here" would not appear
> in the rendered output. But as soon as I installed Django 1.8.3, I started
> seeing the entire "{# comment here %}" text in the rendered output.
>
> Anyone know what code change triggered this altered rendering behavior?
> There's no mention of changes to template comments in any of the release
> notes for Django 1.8.x.
>
--
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 receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/aab52a6d-8565-4efc-91ac-103dbface79f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
