Why deprecate the ability to reverse using the Python path?

[guettli]

Today I realized that the ability to reverse using the Python path gets 
deprecated

My source: https://docs.djangoproject.com/en/1.8/ref/urlresolvers/#reverse

Imagine you have a very clear directory structure and everyone knows this in
your company.

The name of an url pattern is redundant. I like to avoid redundancy (DRY).

I don't see the reasons behind this.

The security issues are already solved: 
https://www.djangoproject.com/weblog/2014/apr/21/security/#s-issue-unexpected-code-execution-using-reverse

Please tell me the reason.

One work around this would be to give each view the name of the import 
path: name="common_structure.foo.bar"
And if you don't allow dots: name="common_structure/foo/bar"
But this looks not dirty.





-- 
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/4d36be10-847a-40f5-9421-5d6e0d6d865c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why deprecate the ability to reverse using the Python path?

[guettli]

Thank you Graham. I will talk with my team mates again.

Moving  to URLs with names is no good solution for us. But maybe using the 
view methods itself.

Since a lazy reverse() exists since some releases now, removing the whole 
string magic might be a good idea.

Thanks to all django developers for your constant updates. It's just hard 
to keep up with your pace :-)



Am Mittwoch, 15. April 2015 12:51:25 UTC+2 schrieb Tim Graham:
>
> Please see the ticket and release notes:
> https://code.djangoproject.com/ticket/22384
>
> https://docs.djangoproject.com/en/1.8/releases/1.8/#passing-a-dotted-path-to-reverse-and-url
>
> If you want to continue using dotted paths, you might be able to create a 
> custom url() function that assigns a name using the view's path and use 
> that in your urlpatterns instead of django.conf.urls.url().
>
> On Wednesday, April 15, 2015 at 4:19:47 AM UTC-4, guettli wrote:
>>
>> Today I realized that the ability to reverse using the Python path gets 
>> deprecated
>>
>> My source: 
>> https://docs.djangoproject.com/en/1.8/ref/urlresolvers/#reverse
>>
>> Imagine you have a very clear directory structure and everyone knows this 
>> in
>> your company.
>>
>> The name of an url pattern is redundant. I like to avoid redundancy (DRY).
>>
>> I don't see the reasons behind this.
>>
>> The security issues are already solved: 
>> https://www.djangoproject.com/weblog/2014/apr/21/security/#s-issue-unexpected-code-execution-using-reverse
>>
>> Please tell me the reason.
>>
>> One work around this would be to give each view the name of the import 
>> path: name="common_structure.foo.bar"
>> And if you don't allow dots: name="common_structure/foo/bar"
>> But this looks not dirty.
>>
>>
>>
>>
>>
>>

-- 
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/7b026328-b554-46de-a324-59d18870c413%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why deprecate the ability to reverse using the Python path?

[guettli]

Dear Graham and django developers,

I talked about this in our team. The pace is to fast. We have about 
thousand urls mappings
that need to be changed to from reverse('mapp.views.foo.bar') to 
reverse(view_method).

We never jumped on the "give the URLs a name" wagon.

What do you gain be disabling this feature? Security is not a concern any 
more.

We think disabling this feature brings drawbacks without advantage.

Related topic:

Using classed_based_view_instance.url instead of 
reverse(classed_based_view_instance) 
would be nice. What do you think?

Quote from ticket 22384 
{{{
Marc mentioned in that ticket "Reversing by dotted path to view is just a 
bad idea."
}}}

Maybe it was a bad idea. It was a bad since reverse() was not lazy many 
versions ago.
This created recursive import errors reverse() got called during importing 
a python file.

Again: Please think about this decision again. I guess many people don't 
want to reformat
their code base just because some said it was "just a bad idea".

Regards,
  Thomas Güttler

Am Mittwoch, 15. April 2015 10:19:47 UTC+2 schrieb guettli:
>
> Today I realized that the ability to reverse using the Python path gets 
> deprecated
>
> My source: https://docs.djangoproject.com/en/1.8/ref/urlresolvers/#reverse
>
> Imagine you have a very clear directory structure and everyone knows this 
> in
> your company.
>
> The name of an url pattern is redundant. I like to avoid redundancy (DRY).
>
> I don't see the reasons behind this.
>
> The security issues are already solved: 
> https://www.djangoproject.com/weblog/2014/apr/21/security/#s-issue-unexpected-code-execution-using-reverse
>
> Please tell me the reason.
>
> One work around this would be to give each view the name of the import 
> path: name="common_structure.foo.bar"
> And if you don't allow dots: name="common_structure/foo/bar"
> But this looks not dirty.
>
>
>
>
>
>

-- 
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/b6d682a8-0e2e-41db-9f01-d152624db79e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

create_permisions(): Call to ContentType.objects.clear_cache() missing

[guettli]

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 primary key 1 before the migration and 
after the migration
it has the value 2, then things get broken.

The cache needs to be cleared first.

Please have a look at it.

Thank you,

  Thomas Güttler

-- 
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/7ab12a7d-1c49-4daa-b516-bc3d2cce6b9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: create_permisions(): Call to ContentType.objects.clear_cache() missing

[guettli]

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 a migration removes all exiting content-types and adds them 
again. But with different PKs.
5. implicit: New permissions created for an existing ContentTypes should be 
created. Up to now an exception happens. (See ticket).

How can I write a unittest which does the above steps?

Regards,
  Thomas

Am Donnerstag, 20. August 2015 13:14:21 UTC+2 schrieb Tim Graham:
>
> 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 and recreates content-types, then the 
>> automatically called create_migrations()
>> can result in ForeignKey constraint errors.
>>
>> Example:
>>
>> If Permission "Can add group" had primary key 1 before the migration and 
>> after the migration
>> it has the value 2, then things get broken.
>>
>> The cache needs to be cleared first.
>>
>> Please have a look at it.
>>
>> Thank you,
>>
>>   Thomas Güttler
>>
>

-- 
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/824a93e2-cd20-474d-9fa0-2c72537202d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#25582: Add a way to build URLs with query strings

[guettli]

>From  https://code.djangoproject.com/ticket/25582

 {{{

It is a common question on stackoverflow and other places:

How to reverse() to url including GET parameters? Example: 
.../myview?foo=bar

​
http://stackoverflow.com/questions/9585491/how-do-i-pass-get-parameters-using-django-urlresolvers-reverse

​http://stackoverflow.com/a/27641445/633961

It would be very nice if django could implement a short-cut which provides
this.
It would be useful for python code and template, too.
}}}

{{{
If we do add it, it likely needs a discussion on the DevelopersMailingList 
 to figure out 
what the API should look like. See also #10941 
 which asks for a template tag 
for creating query strings in templates.
}}}

What do you think?



-- 
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/9d21df96-53dd-4bec-a5ce-adfab971065d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #25582: Add a way to build URLs with query strings

[guettli]

API proposal:

Add a new kwarg to reverse():

   reverse(..., get=None)


Example: reverse('my_view_name', kwargs={'pk': '1'}, get=dict(param='value')

result: /my-view/1?param=value




Am Freitag, 23. Oktober 2015 13:43:18 UTC+2 schrieb Tim Graham:
>
> Can you make an API proposal?
>
> On Friday, October 23, 2015 at 3:41:42 AM UTC-4, guettli wrote:
>>
>> From  https://code.djangoproject.com/ticket/25582
>>
>>  {{{
>>
>> It is a common question on stackoverflow and other places:
>>
>> How to reverse() to url including GET parameters? Example: 
>> .../myview?foo=bar
>>
>> ​
>> http://stackoverflow.com/questions/9585491/how-do-i-pass-get-parameters-using-django-urlresolvers-reverse
>>
>> ​http://stackoverflow.com/a/27641445/633961
>>
>> It would be very nice if django could implement a short-cut which provides
>> this.
>> It would be useful for python code and template, too.
>> }}}
>>
>> {{{
>> If we do add it, it likely needs a discussion on the 
>> DevelopersMailingList 
>> <https://code.djangoproject.com/wiki/DevelopersMailingList> to figure 
>> out what the API should look like. See also #10941 
>> <https://code.djangoproject.com/ticket/10941> which asks for a template 
>> tag for creating query strings in templates.
>> }}}
>>
>> What do you think?
>>
>>
>>
>>

-- 
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/3b42659c-3eb0-4769-94c7-78c49889ae08%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #25582: Add a way to build URLs with query strings

[guettli]

Up to now you can change only one field in your make_query() method.
Flowing "think in sets" it would be nice to update N key-value pairs.


Am Freitag, 23. Oktober 2015 17:18:38 UTC+2 schrieb Collin Anderson:
>
> If it helps, I have a similar need in the template. My case requires 
> adding, removing, or replacing one of the arguments on the fly:
>
> In templates, I often need to change _one_ key of a GET request on the 
> fly. My use case is a "filter by" sidebar on the same page as a "sort by" 
> and "number per page". (Example: http://comcenter.com/category/BC020/ ).
>
> I currently use a simple custom template tag:
> @register.simple_tag
> def make_query(params, key=None, value=None):
> from django.utils.http import urlencode
> if key:
> params = params.copy()
> if value:
> params[key] = value
> else:
> params.pop(key, None)
> return '?' + urlencode(params, True) if params else '.'
>
> For previous/next pages, I simply use:
> 
>
> For more complicated things, in the view I collect all of the valid params 
> and pass them to the template. (I don't keep the "page" key in "params", 
> because I want that to reset when filtering or sorting.)
> 
> 
>
> I can remove keys like so:
> Show All
>
> On Friday, October 23, 2015 at 3:41:42 AM UTC-4, guettli wrote:
>>
>> From  https://code.djangoproject.com/ticket/25582
>>
>>  {{{
>>
>> It is a common question on stackoverflow and other places:
>>
>> How to reverse() to url including GET parameters? Example: 
>> .../myview?foo=bar
>>
>> ​
>> http://stackoverflow.com/questions/9585491/how-do-i-pass-get-parameters-using-django-urlresolvers-reverse
>>
>> ​http://stackoverflow.com/a/27641445/633961
>>
>> It would be very nice if django could implement a short-cut which provides
>> this.
>> It would be useful for python code and template, too.
>> }}}
>>
>> {{{
>> If we do add it, it likely needs a discussion on the 
>> DevelopersMailingList 
>> <https://code.djangoproject.com/wiki/DevelopersMailingList> to figure 
>> out what the API should look like. See also #10941 
>> <https://code.djangoproject.com/ticket/10941> which asks for a template 
>> tag for creating query strings in templates.
>> }}}
>>
>> What do you think?
>>
>>
>>
>>

-- 
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/1685311a-1222-4087-b3a9-7bf6a9500f90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

"Project" vs "App"

[guettli]

I created a ticket to find a better definition of "Project" vs "App"

https://code.djangoproject.com/ticket/25748

I am happy since Tim Graham accepted it.

Here are the current docs: 
https://docs.djangoproject.com/en/1.8/ref/applications/#projects-and-applications

Here is my view of Project" vs "App". It would be nice to find a consensus 
and update the docs.

Project
==
A project is a container for apps.
It contains only settings, no database models.
Since it contains no database models it does not contain database schema 
migrations.
It can contain migrations which fill a database with project specific data.
It is common that there is only one production installation of one project.
It is common to have several stages (dev, test, prod) for one project.
A project might contain a sitecustomize.py

App
===
An app can have models, views and code.
It should be re-usable.
An app can depend on other apps.
It must not depend on a project.
An app can contain a settings.py for testing, but it contains no settings 
on its own.
It should have instructions which settings are needed to get the app 
running in a project.
A app must not contain a sitecustomize.py.

-- 
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/1a7e8d69-1970-4b07-b820-90c4d652486b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: "Project" vs "App"

[guettli]

Am Donnerstag, 19. November 2015 15:12:16 UTC+1 schrieb Collin Anderson:
>
> What's a sitecustomize.py? :)
>


This module is automatically imported during initialization if the 
interpreter.

We use it to:

 - sort sys.path.
 - monkey patching. During the Update from Django 1.6 to 1.7 we added an 
empty django.setup() to make code work on 1.6 and 1.7

See https://docs.python.org/2/library/site.html



 

> I think apps _can_/_may_ be reusable. I have plenty of non-reusable apps. 
> Why should they be reusable?
>

Yes, you are right. In my context we focus on re-usablity. We create 
software which gets used by
several customers (each running in their intranet). If you have only one 
plattform, then the
"should" is too strong. 
 

> I think apps _should_ not depend on a project.
>
>
If an app depends on the project there is a circular dependency. This 
should be avoided.
See https://en.wikipedia.org/wiki/Circular_dependency

That's why I vote for "An app must not depend on a project".

Thank you Collin for your feedback. I still hope some other people join 
this thread.

Regards,
  Thomas 

 

>
> On Thu, Nov 19, 2015 at 4:54 AM, guettli  > wrote:
>
>> I created a ticket to find a better definition of "Project" vs "App"
>>
>> https://code.djangoproject.com/ticket/25748
>>
>> I am happy since Tim Graham accepted it.
>>
>> Here are the current docs: 
>> https://docs.djangoproject.com/en/1.8/ref/applications/#projects-and-applications
>>
>> Here is my view of Project" vs "App". It would be nice to find a 
>> consensus and update the docs.
>>
>> Project
>> ==
>> A project is a container for apps.
>> It contains only settings, no database models.
>> Since it contains no database models it does not contain database schema 
>> migrations.
>> It can contain migrations which fill a database with project specific 
>> data.
>> It is common that there is only one production installation of one 
>> project.
>> It is common to have several stages (dev, test, prod) for one project.
>> A project might contain a sitecustomize.py
>>
>> App
>> ===
>> An app can have models, views and code.
>> It should be re-usable.
>> An app can depend on other apps.
>> It must not depend on a project.
>> An app can contain a settings.py for testing, but it contains no settings 
>> on its own.
>> It should have instructions which settings are needed to get the app 
>> running in a project.
>> A app must not contain a sitecustomize.py.
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/1a7e8d69-1970-4b07-b820-90c4d652486b%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/1a7e8d69-1970-4b07-b820-90c4d652486b%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> 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/188ce7e0-73a3-45f4-81d6-3acaa7bea7ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Feature request: Extend Storage.save() to directly save strings/bytes

[guettli]

To save strings/bytes you need to use ContentFile up to now:

path = default_storage.save('path/to/file', ContentFile(b'new content'))

Docs:  https://docs.djangoproject.com/en/3.1/topics/files/#storage-objects

Things would be bit easier, if save() would support strings/bytes directly.

This way a developer needs to type and import less code.

The implementation would be simple: Storage.save() could check with 
"isinstance()"

if the value needs to be wrapped in ContentFile.

Would you accept a patch to Storage.save()?

Background: I am writing a unittest which mocked away the storage calls to 
save() will put the data into the mock.

Then I check if the data is the way I want it.

Now it gets complicated again: I need to access the data which is 
inside ContentFile grrr.

This would be much easier if you could add strings/bytes to 
the save() directly.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fabd4661-93b9-45f4-a47e-3ffc31abc50cn%40googlegroups.com.

Re: Feature request: Extend Storage.save() to directly save strings/bytes

[guettli]

Adam Johnson schrieb am Donnerstag, 18. Februar 2021 um 10:04:01 UTC+1:

> Hi
>
> If you're mocking away the storage class to speed up your tests, instead 
> try this in-memory storage class which implements the complete API:  
> https://github.com/waveaccounting/dj-inmemorystorage . Then you don't 
> need any mocks.
>
>
Thank you for this hint.
 

> As to adding the shortcut - if the only thing it will help with is your 
> test length, why not write a couple of wrapper functions in your tests? 
>

It is about easier usage for storing strings/bytes and easier testing  (if 
you store strings/bytes).

Of course I can write a wrapper, but I have several django projects. I 
could create a library which exists of one method with one line.
But why not make life easier for all people?
 

> I'm not sure we'd want to add this capability to Django since it would 
> complicate the type signature and would enforce change on all the third 
> party storage classes that exist.
>

I don't only few Storage Implementation override save(), they override 
_save():

example: 
https://github.com/waveaccounting/dj-inmemorystorage/blob/master/inmemorystorage/storage.py#L193


 

>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/45ba5be0-4580-4e7f-823b-50c77c84f91en%40googlegroups.com.

Python PEP for more convenient HTML generation

[guettli]

Hi,

Since I use the html-fragments-over-the-wire pattern (htmx) I create
small function based views returning small html fragments.

Up to now I use format_html().

I am tired of passing in the variables like `foo=foo, bar=bar` into
format_html().

I created a Python PEP to introduce a new way.

The goal is to have something like the convenient f-string syntax
combined with conditional_escape().

The draft is here: 

Template Literals: https://github.com/guettli/peps/blob/master/pep-.rst

I am looking for feedback. Either here or on python-ideas.

If Python would implement this PEP, would you accept patches
to Django to support Template Literals?

Background: I don't like the JS-Frontend madness. Django can
do more than just provide an http API.

Regards,
  Thomas

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/39137657-4b16-42ad-a2ea-4d97ba9382d4n%40googlegroups.com.

Re: Python PEP for more convenient HTML generation

[guettli]

Adam Johnson schrieb am Freitag, 11. Juni 2021 um 10:17:02 UTC+2:

> Hi Thomas
>
> As I understand there wouldn't be much required by Django to support this 
> - just one function. So if it came to Python, I think we'd like to see a 
> working snippet, maybe in a third party package, before merging support.
>
>
Thank you Adam. The change in Django would be tiny. I think only 
HttpResponse and conditional_escape would need a change. I will provide the 
PR if the PEP gets accepted.

 

> In terms of the PEP, - there are already "too many" ways to template a 
> string in Python, so I'm not sure it will be very popular. A few 
> alternatives spring to mind, beyond those discussed in your related forum 
> thread ( 
> https://forum.djangoproject.com/t/rethinking-how-to-create-html-f-string-like-with-conditional-escape/8212
>  
> ).
>
> First, there's syntactic macros in PEP 638 ( 
> https://www.python.org/dev/peps/pep-0638/ ). They would provide some 
> extensibility to Python's grammar, so features like your HTML string would 
> not need to go through PEP's and Python releases. They could just be 
> installable packages. Definitely check that out - it seems like it's still 
> in draft phase though.
>
>
I will have a look at PEP 638.

 

> Second, a related way to emulate such macros currently is with a codec. 
> Check out the future-fstrings package, which backported f-strings to older 
> versions of Python: https://github.com/asottile/future-fstrings . As a 
> "wrapper" text codec, it gets to pre-process the source code before passing 
> it on to Python to execute. You could do your template string 
> transformation with the current version of Python like this.
>
>
I will  have a loot at this. I would be happy if no PEP would be needed.

But one thing is important for me: IDE and linters should understand it.

 

> Third, stack inspection would also allow you to emulate template strings. 
> Take this example:
>
> import inspect
>
> from django.utils.html import format_html
>
>
> def html(string):
> locals_ = inspect.currentframe().f_back.f_locals
> return format_html(string, **locals_)
>
>
> def main():
> name = "Adam"
> statement = "I'm < 120 years old"
> print(html("{name} says {statement}"))
>
>
> if __name__ == "__main__":
> main()
>
>
Because of the lack of IDE/linters support I added this to the "Rejected 
Ideas".

Thank you for your feedback, I will look into your hints.

Regards,
  Thomas

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/10b8b00e-e213-48e2-a9a7-7aa8479aefc5n%40googlegroups.com.

Status of "Replacing get_absolute_url()"

[guettli]

I think this page is outdated:

  https://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl

At the top:

 > This page is a work in progress - I'm still figuring out the extent of 
the problem before I start working out a solution.

No changes since 8 years.

Can someone please update the page?

I don't want much. For me one sentence at the top is enough.

Thank you.

Regads,
  Thomas Güttler

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/722f7e50-6519-4822-a8b6-a9ce037f1866%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Consensus about visual diagrams in the docs.

[guettli]

I once created a simple ascii diagram to explain details of the Django ORM:

https://code.djangoproject.com/ticket/27936

Years ago it took some time for me to understand it. And since then it
came up by new comers in our team several times.

There is agreement on the goal: yes, a visual diagrams in the docs would be 
nice.

But there is no agreement on the strategy.

I think ascii art is fine. Some suggest to use a graphiz plugin in for 
sphinx.

There is no progress because there is no clear consensus up to now.

I do not care for the strategy, I care for the goal.

How to find clear consensus now?

Regards,
   Thomas Güttler

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2f6f3c4e-44cf-4b35-bb09-751828cc4921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Links from django docs to djangopackages.com should be 'officially endorsed' or not?

[guettli]

This ticket was closed as invalid: 
https://code.djangoproject.com/ticket/26159

{{{

Here comes a pull request to add a link to the djangopackages comparison 
grid "Pagination".
Background: The pagination in django core is only very basic. Most people 
want more. I think re-use helps more then re-inventing :-)
}}}


{{{
sergei-maertens

Resolution set to invalid
Status changed from new to closed

I don't think the docs are the appropriate place to point out alternatives. 
I feel if Django starts going down that road, then you should do the same 
not only for pagination, but for forms, views, other db adapters, other 
template engines... I think it's a slippery slope.

While I think that djangopackages.com is a great resource, I'm not sure if 
it (and no other resources) should be 'officially endorsed' by Django in 
the docs.
}}}

I think a lot of time gets wasted by re-inventing stuff. Yes, programmers 
love to program. But time have
changed. There are a lot of great re-usable apps and libraries and 
programmers who wants to
get things done use them.

What do you think for *this* issue: the docs for pagination should point to 
the comparison grid or not?

Regards,
  Thomas Güttler

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ef2de7e2-d122-45f4-80d8-888a27722123%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Links from django docs to djangopackages.com should be 'officially endorsed' or not?

[guettli]

thank you all for your feedback.

I think it would be good to reference from the individual page to the 
matching comparison grid (if one exists). It tells
newcomers: Professionals do re-use, they don't re-invent.

For example the python docs sometimes have a box called "See also" which 
contains links to related pages.

I found such a box at the bottom of "hashlib": 
https://docs.python.org/2/library/hashlib.html#key-derivation

Regards,
  Thomas Güttler

Am Dienstag, 2. Februar 2016 15:45:23 UTC+1 schrieb Sergei Maertens:
>
> My main concern is that it might appear that Django officially endorses 
> the website, and that it might not be clear to developers that Django isn't 
> directly involved with all those third party packages - which could be 
> potentially harmful.
>
> I'm also think that if you start linking to a grid for pagination, that 
> you should do so for alternative form libraries, template engines, maybe 
> even ORM-stuff if that exists. Basically for every (small or big) component 
> that Django offers. Markus explained it better by using the term 'scattered 
> all over the documentation'.
>
> I would have no problems with a page/section in the docs where libraries 
> or resources like djangopackages.com are linked, centralized in a single 
> place. You lose the relevance on the subject at hand though.
>
> DRF links to extensions, where I assume that Tom has checked all of them 
> and deemed them worthy. It links to a known set of packages, and to me it 
> seems that Tom officially endorses them and finds the quality sufficicient. 
> That's something you don't get with a link to a grid comparison where the 
> content can change multiple time per day.
>
> On Monday, February 1, 2016 at 12:06:23 PM UTC+1, Federico Capoano wrote:
>>
>> It seems like a good proposal, It would be good to know why Sergei 
>> doesn't think it is appropiate for Django to add links to third party 
>> package comparison grids.
>>
>> django-rest-framework links to third party extensions in its 
>> documentation and this had a positive effect on the whole DRF ecosystem.
>>
>> Federico
>>
>>
>> On Monday, February 1, 2016 at 10:39:44 AM UTC+1, guettli wrote:
>>>
>>> This ticket was closed as invalid: 
>>> https://code.djangoproject.com/ticket/26159
>>>
>>> {{{
>>>
>>> Here comes a pull request to add a link to the djangopackages comparison 
>>> grid "Pagination".
>>> Background: The pagination in django core is only very basic. Most 
>>> people want more. I think re-use helps more then re-inventing :-)
>>> }}}
>>>
>>>
>>> {{{
>>> sergei-maertens
>>>
>>> Resolution set to invalid
>>> Status changed from new to closed
>>>
>>> I don't think the docs are the appropriate place to point out 
>>> alternatives. I feel if Django starts going down that road, then you should 
>>> do the same not only for pagination, but for forms, views, other db 
>>> adapters, other template engines... I think it's a slippery slope.
>>>
>>> While I think that djangopackages.com is a great resource, I'm not sure 
>>> if it (and no other resources) should be 'officially endorsed' by Django in 
>>> the docs.
>>> }}}
>>>
>>> I think a lot of time gets wasted by re-inventing stuff. Yes, 
>>> programmers love to program. But time have
>>> changed. There are a lot of great re-usable apps and libraries and 
>>> programmers who wants to
>>> get things done use them.
>>>
>>> What do you think for *this* issue: the docs for pagination should point 
>>> to the comparison grid or not?
>>>
>>> Regards,
>>>   Thomas Güttler
>>>
>>>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6eb3d40e-8b6c-4b70-b3c5-8dc679520532%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Status of DEP 0005: Improved middleware?

[guettli]

I like the improved middleware proposal: 
https://github.com/django/deps/blob/master/draft/0005-improved-middleware.rst

What is the status of it?

Is there an agreement under the django-core developers that the proposal is 
the right direction?

Regards,
  Thomas Güttler

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fd710db7-b4f0-4ef0-b461-4d50b0948327%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Status of DEP 0005: Improved middleware?

[guettli]

Thank you. I am happy that this gets solved.

Am Dienstag, 15. März 2016 15:54:26 UTC+1 schrieb Tim Graham:
>
> Here's the mailing list thread: 
> https://groups.google.com/d/topic/django-developers/8LMJ44KAxWI/discussion
>
> I think mostly the implementation just needs to be completed.
>
> On Tuesday, March 15, 2016 at 10:32:15 AM UTC-4, guettli wrote:
>>
>> I like the improved middleware proposal: 
>> https://github.com/django/deps/blob/master/draft/0005-improved-middleware.rst
>>
>> What is the status of it?
>>
>> Is there an agreement under the django-core developers that the proposal 
>> is the right direction?
>>
>> Regards,
>>   Thomas Güttler
>>
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/331ea0fe-8749-4466-bd62-c212dab27d69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Decoupling Permission-Check from Calling the View

[guettli]

I would like to decouple the permission checking in django.

Current draw-back: If you use decorators like  [login_required][1], then 
you can't know in advance whether a user has the permission to do so or not.

I would like to split this into two steps:

 1. check permissions
 1. call the view.


# Use Case 1: Admin tool
I want an tool for admins where they can check the access-permissions of 
users. This requires:

 1. The check must not use the current `request.user` since this is the 
wrong user object.
 1. The check must not actually call the view, since this might alter data.

# Use Case 2: Show Link as disabled.

I want to show links as disabled (grayed out and without "href") if a user 
does not have the permission to see linked page.

# Dream
Returning a boolean for "ok" and "permission denied" is nice. But the big 
benefit would be if the admin could get a **reason**.

Example: 

 1. Admin opens "Check Perm Tool"
 1. He selects a view/URL
 1. The admin hits "submit"


Result:

--
| User | Allowed | Reason
--
| fooadmin |  Yes| is_superuser
| foouser  |  No | missing permission "view-bar-at-midnight"
| foobar   |  Yes| User has permission "view-bar-at-midnight"

# Question
How to get this dream come true?


  [1]: 
https://docs.djangoproject.com/en/1.9/topics/auth/default/#django.contrib.auth.decorators.login_required







-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bad970d5-182c-4ad7-9dd9-fb0424291e40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Decoupling Permission-Check from Calling the View

[guettli]

Am Dienstag, 26. April 2016 16:27:32 UTC+2 schrieb Alasdair Nicol:
>
> I haven't needed to explain why permission has been granted, but I have 
> had admins asking me why a user is getting permission denied for a 
> particular view. To answer that, you would
>
> 1. Get the url
> 2. Resolve that to a view
> 3. Look up the view in the correct views.py, and check which permissions 
> the permissions_required decorator was using
>
> We managed to automate 1. and 2. but not 3. 
>
> In Django 1.9, the permission_denied view takes the exception as the 
> second argument. If the permission_denied decorator included the permission 
> names in the message when raising PermissionDenied, we would be able to 
> display the list of permissions in the template. Even better, you could 
> show the missing permissions, although that would require a larger patch.
>
>
I am not 100% sure I understood you. Do you mean this:

1. Users/Browser sends http request to django
2. App checks the permissions
3. App denies the access
4. App renders a custom Permission-Denied page which includes the missing 
perms. 
Example: "You must not access this page since you don't have the 
permissions "See Guido naked"

I would like to have this, too. But security experts will tell you: "Don't 
show more than 'permission denied'. Otherwise
evil hackers get more information and systems get hacked more easily."

My steps are like this:

1, 2, 3 like above

4. App renders "permission denied. Ask you admin why you must not access 
the url https://example.com/";
5. User goes to admin crying: "I must not access this url, but I want to 
see "
6. Admin enters username and URL in an admin tool, and there he sees: Ah, 
user is missing perm "See ". 
  One mouse-click by admin: Now you have the perm :-)



 

> Another option would be for the permission_required decorator to set a 
> _permissions attribute on the decorated view, containing the list of 
> permissions. A custom permission_denied view could then introspect the view.
>
> cheers,
> Alasdair
>
>
>>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0ecfcf2b-eeb7-4fdf-a81a-b6159f471e8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ***SPAM*** Re: Middleware+Transactions:

[guettli]

Am Dienstag, 10. Mai 2016 02:07:30 UTC+2 schrieb Kevin Tran:
>
> Thomas, did you ever find a solution to your problem?  I'm having similar 
> thoughts and am looking for an answer.
>
>

Carl Meyer has worked out an enhancement proposal, here is the 
pull-request: https://github.com/django/django/pull/6501


-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/85e8ea1f-a9af-42fa-81e3-c218d217d9e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Template Tag `url` returns empty string, does not raise NoReverseMatch

[guettli]

If you use this syntax, then no NoReverseMatch exception gets raised:

{% url 'some-url-name' arg arg2 as the_url %}

This is documented here: 
https://docs.djangoproject.com/en/1.9/ref/templates/builtins/#url

> This {% url ... as var %} syntax will not cause an error if the view is 
> missing.
> In practice you’ll use this to link to views that are optional ...

This caused an error on a production system which was not detected in CI.

Is the current implementation really the way you like it?

Do you use the following use case provided in the docs?

> % url 'some-url-name' as the_url %}> {% if the_url %}
>  Link to optional stuff> {% endif %}

Regards,
  Thomas Güttler

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/74b6df31-916e-4924-acc4-56db553da4db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Autocomplete in Django 1.11: Widget in Forms Library?

[guettli]

I am happy that there will be support for autocomplete in the admin in 
1.11, if this issue/pull-request gets resolved:

https://code.djangoproject.com/ticket/14370

https://github.com/django/django/pull/6385/

I looked at the changes of the docs of this pull request.

It seems that only the contrib module "admin" gets improved.

Is it planed to add an autocomplete widget in the django forms library?



-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/37be52f6-8aa6-428c-a6ba-24c17424102b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Autocomplete in Django 1.11: Widget in Forms Library?

[guettli]

Am Dienstag, 20. September 2016 13:30:33 UTC+2 schrieb Tim Graham:
>
> I haven't seen that proposal. This type of widget would be new territory 
> for django.forms as none of the existing widgets require JavaScript. I lean 
> toward keeping things that way, but I'm open to hearing counterarguments. 
> Historically, Django avoided "blessing" any particular JavaScript libraries.
>


OK, I see you don't want widgets which require JS in django core. I can 
understand this.

But since contrib.admin includes the autocomplete, it could be possible to 
provide such a widget in contrib.admin. 

My intention: since the admin includes JS for autocomplete, it would be 
nice to re-use this in custom apps.

I know that I can use third party libraries to get this. But if it is 
already in contrib.admin, it would be nice to avoid duplication


 

> On Tuesday, September 20, 2016 at 6:51:24 AM UTC-4, guettli wrote:
>>
>> I am happy that there will be support for autocomplete in the admin in 
>> 1.11, if this issue/pull-request gets resolved:
>>
>> https://code.djangoproject.com/ticket/14370
>>
>> https://github.com/django/django/pull/6385/
>>
>> I looked at the changes of the docs of this pull request.
>>
>> It seems that only the contrib module "admin" gets improved.
>>
>> Is it planed to add an autocomplete widget in the django forms library?
>>
>>
>>
>>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a4411d55-6db2-4515-b680-0b8dfe03a3bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Deprecate is_superuser, is_staff and is_active

[guettli]

I know this is a crazy idea, and it will get the "won't fix" tag very soon.

Nevertheless I want to speak it out.

My use case: Get a queryset of users who have a given permission.

I would like to get this with a simple SQL statement.

At the moment this query is complex and results in performance issues, since
several outer joins get created. See: 
https://groups.google.com/forum/#!topic/django-users/lUGkZybXllM

is_superuser and is_staff could be changed to permissions easily.

It's different with is_active. But again: a simple SQL to get all users 
which have a given permission is my goal.

I personally could live without is_active: Just remove all permissions for 
this user.

If you don't like dropping all perms to make a user inactive since you want 
to switch back and forward between active and inactive   ...
then this a different (bigger) problem: switching back and forward between 
states. Why not solve
this for all models (not just User instances)? But this is a different 
topic :-)

I know the road to deprecate these three friends would be hard since a lot 
of code uses them.

What do you think?






-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/961fd91c-3954-4c7f-a05e-807f2863dc5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

[guettli]

Am Freitag, 24. März 2017 12:42:03 UTC+1 schrieb Andrew Ingram:
>
> I've always felt that `is_staff` should be changed to a permission such as 
> `can_access_admin` provided by the Admin app itself. 
>

 

> However, `is_superuser` is slightly different, in that it's not a 
> permission, but rather a flag that says "this user has EVERY permission". 
> It's also potentially nonsensical from a functional perspective, you could 
> have two permissions that are intended to be mutually exclusive, but a 
> superuser would nonetheless have both of them - potentially resulting in a 
> broken/nonsense UI.
>

Thank you for this easy to understand use case. I ask myself if "this user 
has EVERY permission" is needed at all. If the user should have all 
permissions, then why not give
him all these permissions at database level? It's like a very special 1:N 
relation which is: 1:∞  :-)



 

> This is the main reason why almost nobody should be a superuser (yet 
> nearly every Django project i've inherited has nearly every member of staff 
> marked as superusers).
>
>
Unfortunately we detected this "best practice" too late. We need to switch 
now, but this not related to django-dev, this needs to be solved in our 
company.

 

> `is_active` is intended to be used a little differently isn't it? It's not 
> saying "user has no permissions", it's saying "user is disabled". It's not 
> access-control, it's data.
>
>
Let's look at our use case: I want a queryset of all users which have a 
given permission. Do I want to be
inactive users in this queryset?  I am unsure. But I am sure: I want this 
queryset to be simple at SQL level.

 

> I think that most of it could do with a rethink, but `is_staff` is 
> probably the biggest wart.
>
> Andy
>
>
>

Thanky you Andy

Regards,
  Thomas 

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/66dc2010-eca4-409f-9dea-f1a4f5aa8217%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

[guettli]

Am Freitag, 24. März 2017 13:41:10 UTC+1 schrieb Tim Graham:
>
> I don't think the current fields are so bad or nonsensical that it 
> warrants a change. Also, consider that every Django user would have to 
> learn how to use a new permissions setup.
>
> If you don't like the default permissions structure, use a custom user 
> model.
>
>

Yes, I guess we will go this way.

Are there established third party solutions? . I could not find any 
with my favorite search engine ...

Thank you Tim

Regards,
  Thomas
 

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/945701ea-37d5-4c48-a115-d172edc61ad4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

[guettli]

Am Freitag, 24. März 2017 14:12:44 UTC+1 schrieb Collin Anderson:
>
> Hi Thomas,
>
> "If the user should have all permissions, then why not give him all these 
> permissions at database level?" - I have some use cases where there are 
> only 3-5 people that need to log into the admin. I don't really need to set 
> different levels of access for different people. I also don't want to have 
> to go through and add new permissions to every person every time I add a 
> model. So, I just mark them all as is_superuser and don't use permissions 
> at all. It keeps things simple.
>
> Something like this might handle your situation:
> class MyUser:
> # etc
> is_superuser = False
> is_staff = property(lambda u: u.has_perm('admin'))
>
>
Yes, configuring permission each time you add a model makes no fun. I have 
to think about this again.

Regards,
  Thomas Güttler

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/abd56b3b-a0af-4fd8-847e-1ea7d06dd9b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

[guettli]

Am Montag, 27. März 2017 16:11:06 UTC+2 schrieb Melvyn Sopacua:
>
> On Friday 24 March 2017 04:31:32 guettli wrote:
>
> > I know this is a crazy idea, and it will get the "won't fix" tag very
>
> > soon.
>
> > 
>
> > Nevertheless I want to speak it out.
>
> > 
>
> > My use case: Get a queryset of users who have a given permission.
>
>  
>
> I'm still thinking about this use case.
>
> Cause it's not for normal use - you don't normally use permissions as 
> data, you use permissions to deny / allow access to data.
>
> So, you're already in the "specialized" corner.
>
>  
>


I can use more words, to make this use case more colorful.

Imagine a approval workflow: Only some users are allowed to do the approval.

An invoice instance needs to be forwarded to someone with the matching 
permissions.

This way I want to provide a html form where the current user can choose 
the user with the matching
permissions.




 

> > At the moment this query is complex and results in performance issues,
>
>  
>
> For a small install this works fine. When performance becomes an issue 
> because there's a large number of users and groups, my first instinct is to 
> regroup users so that no permission exceptions exist anymore at the user 
> level.
>
> I'd add all superusers to the "wheel" group ("root", "superuser", whatever 
> floats your boat).
>
> Now the query to get this info no longer requires the user model for 
> conditions and you can simply query the group manager.
>
> It is what groups are for and it'll be always faster get all the matching 
> groups as one set and combine it with all the users that have the 
> permission assigned directly.
>
> The "one query" requirement conflicts with your performance requirement.
>
>

Unfortunately the current sql query has several outer joins and takes 
several seconds even with only very few data in the database.

We have a work-around this. The basic part is published here: 
https://code.djangoproject.com/ticket/27260#comment:10



 

>  
>
> -- 
>
> Melvyn Sopacua
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8803a089-4497-47a8-bfcd-3fe31e0d9ffb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

[guettli]

Thank you for the inspiring conversation.

Am Dienstag, 28. März 2017 14:31:33 UTC+2 schrieb Melvyn Sopacua:
>
>
>   
>
> From an object perspective, you need to send the invoice to the group 
> "Approvers". Again, best solved at the group level.
>
> And it's questionable if superusers should be in there. They are the 
> equivalent of the Posix 'root' user, which has the power to lock/unlock 
> everything in and about the system. Data privilege and system privilege are 
> always in fight and in this case it's questionable if superusers should 
> automatically be Approvers and while they still could do it, the UI 
> shouldn't present them.
>
>

My favorite search engine did not reveal much to the topic "Data privilege 
vs system privilege". Do you have any further readings about this topic?



 

>  
>
> As said, a good group structure solves a lot of your problems -
>
>  
>


Yes, groups exist as container/list data type for users.

On the other hand just because groups exist, I think there are other ways 
to specify a list of users. Example: All people with a particular OCEAN 
Vector 

> in fact you wouldn't need a user selection to begin with, as the mail can 
simply be sent to all members of the Approvers group.

A mail to everyone is like a mail to no one (not always, but often).

Again  system vs data privs ... sounds interesting.

Regards,
  Thomas Güttler

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/12b2c209-3e24-4cc9-b7e2-40df744d92c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Debugging Django

[guettli . google]

On Fri, Nov 09, 2007 at 08:32:15AM -0700, John M. Anderson wrote:
> > You cannot debug a single Django file in isolation. Instead, insert this
> > line:
> >
> >import pdb; pdb.set_trace()
> >
> > in sql.py, at the point you're interested in. Then run Django normally,
> > and
> > go to a db-based URL: you'll get a debugger prompt.
> >
> 
> ok, thanks. I was just trying to debug without modifying files, it seems
> silly
> to have to modify the files to debug, but i'm new to python.

If you are new to python: You don't need a debugger. 

Set up your servert, so that code gets reloaded automatically (either 'manage.py
runserver' or mod_python with 'MaxRequestsPerChild 1'). Then 
you can add 'assert False' or for example 
'assert False, django.db.connection.queries' into the code you want
to inspect. This will give you a lot of information if DEBUG=True is
set in settings.py.

Or: you can set up the logging module and add lines like
logging.info("foo: %s" % (foo)) into the code.

If you are new to python and django, you can ask on the user mailinglist
first.

 Thomas

-- 
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---