Re: Ticket/Issue Tracker

[Dan Davis]

Collin, 

Are you using an inverted index (search engine) behind that for relevance 
ranking, better word segmentation/stemming/synonyms, and peirformance?
I think that something like that is really needed when the problem is 
finding stuff.

On Friday, October 26, 2018 at 9:50:43 PM UTC-4, Collin Anderson wrote:
>
> A few years ago I realized I really liked the UI of Trello.com, so I tried 
> creating a trello-style view of django tickets:
>
> https://djello.collinand.org/ (beware, I'm not a designer :)
>
> It's basically just 100 lines of JS and a little CSS. It's still my go to 
> for finding tickets.
>
> I thought I'd share that as an idea for how to improve find-ability.
>
>
> -- Forwarded message -
> From: Tom Forbes
> Date: Fri, Oct 26, 2018 at 8:09 PM
> Subject: Re: Widening participation (Thoughts from DjangoCon)
>
> How much of this would you attribute to the current ticketing system 
> itself, rather than tickets being tagged appropriately?
>
> I know when I started contributing I found trac to be pretty intimidating 
> in terms of complexity, especially the search. I still prefer to use the 
> 'Search Trac' field in the root code.djangoproject.com page than fiddle 
> with the myriad of options and drop downs in the browse tickets section.
>
> If we think of getting new people onboard as a conversion funnel we need 
> to stop dropoff as much as possible, and that extends to the UI of the 
> ticket tracker as well I believe.
>
> Tom
>
> On Fri, 26 Oct 2018, 22:43 Ian Foote wrote:
>
>> Hi Carlton,
>>
>> I've had similar thoughts sitting in the back of my mind for at least a 
>> couple of months, so thank you for sharing this. I agree that finding 
>> tickets is one of the big problems here, both for new contributors and for 
>> sprint leaders. At Pycon UK I took on the role of sprint leader along with 
>> Adam Johnson and directing people to appropriate tickets was a definite 
>> difficulty. I was also unaware of the django core mentorship list and will 
>> be joining that soon. I'm willing to spend some time mentoring a small 
>> number of people, life permitting.
>>
>> Ian
>>
>> On Fri, 26 Oct 2018 at 14:44, Carlton Gibson wrote:
>>
>>> Hi All. 
>>>
>>> OK, so last week I was at DjangoCon US in San Diego. (Thank you if you 
>>> organised that! Hi! if we met and chatted.) 
>>> I gave a talk ("Your web framework needs you!") inspired by the 
>>> discussion on the 
>>>  DSF 
>>> list and the proposal to dissolve Django Core 
>>> . (Can’t see the DSF list? Join 
>>> the DSF 
>>> 
>>> .)
>>> I was asking for more participation in general, and participation that 
>>> is more representative of the wider Django community in particular.
>>>
>>> There was lots of good input from many people, including (but not, at 
>>> all, limited to) representatives of groups such Pyladies, DjangoGirls, and 
>>> so on. 
>>>
>>>
>>> The recurring themes seem to me to fit into three categories:
>>>
>>>1. The importance of *mentoring*.
>>>2. The difficulty of *finding tickets*.
>>>3. The importance of *sprints*.
>>>
>>> The rest here is a summary of that. Hopefully it’s useful. 
>>>
>>> Finding Tickets
>>>
>>> The next thing was that there’s not enough guidance on what to work on. 
>>>
>>> The guidance is to look for *Easy Pickings*. There are ≈1300 accepted 
>>> open tickets in TRAC. 13 of these are marked *Easy Pickings*. 
>>>
>>> That’s not enough. I think we’re too tight with it (or need another 
>>> grade). 
>>>
>>> There are *many* tickets which aren’t super hard: I put it that, most 
>>> of our community solve harder problems every day *using Django* than 
>>> most tickets require. 
>>>
>>> Yes, they still require time, love, energy, etc — and maybe some 
>>> mentoring — but it’s not primary research, in the main.
>>>
>>> I talked to people who had (at the conference) got the test suite 
>>> running and such, but been overawed by the (for want of a better phrase) 
>>> *sheer 
>>> face* of issue tracker. 
>>>
>>> We would do well to invite people better here. (I don’t have instant 
>>> solutions.) 
>>>
>>

-- 
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/d52ed4e1-ad0d-42d8-9d3f-7f3e4be2a0b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proposal to extend support for object permission

[Tobias Bengfort]

Hi,

as far as I understand the documentation[1], django's architecture
supports object permissions, but external apps like django-rules or
django-guardian are supposed to provide actual implementations.

I think this approach is great. However, I believe that there are some
key points where django core should provide more tooling so that the
external apps can concentrate more on building the actual authentication
backends.

# DefaultObjectBackend (#20218)

ModelBackend always returns `False` if an object is passed. Many
developers expect object permissions to be a superset of model
permissions. A DefaultObjectBackend could be added that does exactly
that. By implementing it as a separate backend it is fully optional and
does not break backwards compatibility.

```
class DefaultObjectBackend:
def authenticate(self, username, password):
return None

def get_user_permissions(self, user, obj=None):
if obj is None:
return set()
return user.get_user_permissions()

def get_group_permissions(self, user, obj=None):
if obj is None:
return set()
return user.get_group_permissions()

def get_all_permissions(self, user, obj=None):
if obj is None:
return set()
return user.get_all_permissions()

def has_perm(self, user, perm, obj=None):
if obj is not None:
return user.has_perm(perm)
```

# PermissionRequiredMixin.get_permission_object()

Currently, external apps have to ship their own mixin because the
default one does not support object permissions. A new method
`get_permission_object()` could be added. This is what django-guardian
does. However, in django core it should return None by default for
backwards compatibility (In django-guardian it falls back to
`get_object()`).

```
class PermissionRequiredMixin:
…

def get_permission_object(self):
return None

def has_permission(self):
perms = self.get_permission_required()
permission_object = self.get_permission_object()
return self.request.user.has_perms(perms, obj=permission_object)
```

# has_perm template tag

Just as with PermissionRequiredMixin, the current way to check for
permissions in templates does not support object permissions. A new
has_perm template tag could be added that simply calls
`user.has_perm()`. This approach is used by django-rules.

```
@register.simple_tag
def has_perm(perm, user, obj=None):
return user.has_perm(perm, obj)
```

# Add a BaseBackend

Currently, writing an authentication backend is not as straight-forward
as it could be. I propose to add a BaseBackend that implements some sane
defaults:

```
class BaseBackend:
def authenticate(self, username, password):
return None

def get_user_permissions(self, user, obj=None):
return set()

def get_group_permissions(self, user, obj=None):
return set()

def get_all_permissions(self, user, obj=None):
perms = set()
perms.update(self.get_user_permissions(user, obj=obj))
perms.update(self.get_group_permissions(user, obj=obj))
return perms

def has_perm(self, user, perm, obj=None):
perms = self.get_all_permissions(user, obj=obj)
return perm in perms
```

All of these changes can easily be implemented and have little to no
backwards incompatibility. However, they would provide a much stronger
base for object permission in core. I am not sure whether this is
desired from either the core team or the developers of external
authentication apps though.

What do you think? Should I proceed writing pull requests for the
proposed changes?

tobias


[1]:
https://docs.djangoproject.com/en/2.1/topics/auth/customizing/#handling-object-permissions

-- 
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/c50b1518-9f7c-d090-a40b-70995bf2f731%40posteo.de.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket/Issue Tracker

[Adam Johnson]

Djello is nice, bookmarked!

On Sat, 27 Oct 2018 at 02:50, Collin Anderson  wrote:

> A few years ago I realized I really liked the UI of Trello.com, so I tried
> creating a trello-style view of django tickets:
>
> https://djello.collinand.org/ (beware, I'm not a designer :)
>
> It's basically just 100 lines of JS and a little CSS. It's still my go to
> for finding tickets.
>
> I thought I'd share that as an idea for how to improve find-ability.
>
>
> -- Forwarded message -
> From: Tom Forbes
> Date: Fri, Oct 26, 2018 at 8:09 PM
> Subject: Re: Widening participation (Thoughts from DjangoCon)
>
> How much of this would you attribute to the current ticketing system
> itself, rather than tickets being tagged appropriately?
>
> I know when I started contributing I found trac to be pretty intimidating
> in terms of complexity, especially the search. I still prefer to use the
> 'Search Trac' field in the root code.djangoproject.com page than fiddle
> with the myriad of options and drop downs in the browse tickets section.
>
> If we think of getting new people onboard as a conversion funnel we need
> to stop dropoff as much as possible, and that extends to the UI of the
> ticket tracker as well I believe.
>
> Tom
>
> On Fri, 26 Oct 2018, 22:43 Ian Foote wrote:
>
>> Hi Carlton,
>>
>> I've had similar thoughts sitting in the back of my mind for at least a
>> couple of months, so thank you for sharing this. I agree that finding
>> tickets is one of the big problems here, both for new contributors and for
>> sprint leaders. At Pycon UK I took on the role of sprint leader along with
>> Adam Johnson and directing people to appropriate tickets was a definite
>> difficulty. I was also unaware of the django core mentorship list and will
>> be joining that soon. I'm willing to spend some time mentoring a small
>> number of people, life permitting.
>>
>> Ian
>>
>> On Fri, 26 Oct 2018 at 14:44, Carlton Gibson wrote:
>>
>>> Hi All.
>>>
>>> OK, so last week I was at DjangoCon US in San Diego. (Thank you if you
>>> organised that! Hi! if we met and chatted.)
>>> I gave a talk ("Your web framework needs you!") inspired by the
>>> discussion on the
>>>  DSF
>>> list and the proposal to dissolve Django Core
>>> . (Can’t see the DSF list? Join
>>> the DSF
>>> 
>>> .)
>>> I was asking for more participation in general, and participation that
>>> is more representative of the wider Django community in particular.
>>>
>>> There was lots of good input from many people, including (but not, at
>>> all, limited to) representatives of groups such Pyladies, DjangoGirls, and
>>> so on.
>>>
>>>
>>> The recurring themes seem to me to fit into three categories:
>>>
>>>1. The importance of *mentoring*.
>>>2. The difficulty of *finding tickets*.
>>>3. The importance of *sprints*.
>>>
>>> The rest here is a summary of that. Hopefully it’s useful.
>>>
>>> Finding Tickets
>>>
>>> The next thing was that there’s not enough guidance on what to work on.
>>>
>>> The guidance is to look for *Easy Pickings*. There are ≈1300 accepted
>>> open tickets in TRAC. 13 of these are marked *Easy Pickings*.
>>>
>>> That’s not enough. I think we’re too tight with it (or need another
>>> grade).
>>>
>>> There are *many* tickets which aren’t super hard: I put it that, most
>>> of our community solve harder problems every day *using Django* than
>>> most tickets require.
>>>
>>> Yes, they still require time, love, energy, etc — and maybe some
>>> mentoring — but it’s not primary research, in the main.
>>>
>>> I talked to people who had (at the conference) got the test suite
>>> running and such, but been overawed by the (for want of a better phrase) 
>>> *sheer
>>> face* of issue tracker.
>>>
>>> We would do well to invite people better here. (I don’t have instant
>>> solutions.)
>>>
>> --
> 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/3b85c677-9244-46f4-b526-bf919bd74057%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from th

Allow querying JSONField with F objects #29769

[Mani S]

Django's F objects does not perform JSON lookups. A ticket has been raised 
for the same https://code.djangoproject.com/ticket/29769

I have written a customer expression for querying JSONField and
* it works!*

class KeyTextTransformFactory:

def __init__(self, key_name):
self.key_name = key_name

def __call__(self, *args, **kwargs):
return KeyTextTransform(self.key_name, *args, **kwargs)

class JSONF(F):

def resolve_expression(self, query=None, allow_joins=True, reuse=None, 
summarize=False, for_save=False):
rhs = super().resolve_expression(query, allow_joins, reuse, summarize, 
for_save)

field_list = self.name.split(LOOKUP_SEP)
for name in field_list[1:]:
rhs = KeyTextTransformFactory(name)(rhs)
return rhs

It is necessary to include Cast in rhs,
Sample.objects.filter(jsonfield__lookup__value=Cast(JSONF('value'), 
IntegerField())) 


Comment ref: https://code.djangoproject.com/ticket/29769#comment:5


Note: This is my first contribution in Django source code, any 
comments/suggestions would help me learn the process better.





Thank you,
Mani

-- 
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/88f52ca0-ebd9-4139-b88e-9f21292b7603%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports - October 2018

[Tim Graham]

Week ending October 27, 2018

Triaged

---

https://code.djangoproject.com/ticket/29881 - Invalid SQL on MySQL with 
Cast to DecimalField (duplicate)

https://code.djangoproject.com/ticket/29890 - FileSystemStorage._save() 
doesn't catch FileExistsError on concurrent os.mkdirs() (accepted)

Authored

--

https://github.com/python/cpython/pull/10082 - bpo-31047: Fix 
ntpath.abspath to trim ending separator

https://github.com/django/django/pull/8117 - Refs #27025 -- Removed 
obsolete sqlite3 transaction management workaround for Python 3.6+.

https://github.com/django/django/pull/10570 - Fixed #28606 -- Deprecated 
CachedStaticFilesStorage.

https://github.com/django/django/pull/10573 - Fixed #29896 -- Fixed 
incorrect Model.save() cache relation clearing for foreign keys that use 
to_field.

Reviewed/committed

--

https://github.com/django/django/pull/10541 - Fixed #27595 -- Made 
ForeignKey.get_col() follow target chains.

https://github.com/django/django/pull/10522 - Fixed #29860 -- Allowed 
BaseValidator to accept a callable limit_value.

https://github.com/django/django/pull/10526 - Fixed #29830 -- Fixed loss of 
custom utf-8 body encoding in mails. 

https://github.com/django/django/pull/10535 - Fixed #29831 -- Added 
validation for makemigrations --name.

https://github.com/django/django/pull/10537 - Fixed #29721 -- Ensured 
migrations are applied and recorded atomically.

https://github.com/django/django/pull/10555 - Fixed #29534 -- Made dbshell 
use rlwrap on Oracle if available.
https://github.com/django/django/pull/10559 - Fixed #29763 -- Added support 
for column renaming on SQLite.

-- 
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/c4b75c05-430a-4f3c-a9c8-18c94eff8a80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Requiring sqlparse for sqlite introspection

[charettes]

After a bit of work to minimize the cases where sqlparse would be a 
required at runtime for SQLite to AddConstraint/RemoveConstraint operations 
[0] I came to the conclusion that it would make more sense to make sqlparse 
an hard dependency of Django 2.2.

The two reasons backing this conclusions are

1. Given we run the suite with sqlparse installed on CI it will be really 
hard to prevent inadvertently breaking the promise of a soft dependency on 
sqlparse for Meta.constraints only. I guess we could have a daily CI job 
but that would quickly get out of hand once we have to perform backport and 
such.

2. There's a few instances of fragile regex parsing that could be made more 
reliable if sqlparse was an hard dependency for SQLite. Two examples are
 - 
https://github.com/django/django/blob/f892781b957f674806a227a10c58768f66a48c07/django/db/backends/sqlite3/introspection.py#L90-L146
 - 
https://github.com/django/django/blob/f892781b957f674806a227a10c58768f66a48c07/django/db/backends/sqlite3/schema.py#L91-L127

Given the transition to require pytz in Django 1.11 went smoothly and our 
needs for sqlparse are similar to provide a solid experience on SQLite I'd 
be +1 on requiring it from Django 2.2 to a point where the lowest version 
of SQLite we support has better introspection capabilities.

Simon

[0] https://github.com/django/django/pull/10572

Le mercredi 10 octobre 2018 14:53:53 UTC-4, Tim Graham a écrit :
>
> sqlparse is already installed as part of Django's tests. The question is 
> whether sqlparse should be mandatory for SQLite users (i.e. when getting 
> started with a new project an error message will say, "You must install 
> sqlparse to use SQLite" (I don't think there's a way to install it 
> automatically unless we install it for all users, regardless of database) 
> or if we should try to make it optional and only raise an error if a 
> project's migrations require it.
>
> The question is "what percentage of SQLite projects are going to end up 
> needing sqlparse based on their migrations? If it's high enough, it might 
> make for a better user experience to have users install it when they're 
> getting started instead of a lazy error when get_constraints() is called."
>
> On Monday, October 8, 2018 at 3:22:32 AM UTC-4, Andrew Godwin wrote:
>>
>> Adding sqlparse into the introspection code for SQLite specifically means 
>> it's going to be a runtime dependency for anything to do with migrations.
>>
>> I'm alright having that be the case, but I do think we should make sure 
>> the tests run with SQLite as otherwise a large section of the most 
>> complicated code in migrations won't be tested properly.
>>
>> Andrew
>>
>>
>> On Mon, 8 Oct 2018, 00:59 Ian Foote,  wrote:
>>
>>> Hi all,
>>>
>>> On my pull request (https://github.com/django/django/pull/10406) 
>>> refactoring how Django creates database constraints I introduced a 
>>> dependency on sqlparse in the sqlite introspection code. This allows Django 
>>> to correctly read information about constraints on sqlite, particularly the 
>>> name.
>>>
>>> When reviewing (
>>> https://github.com/django/django/pull/10406#issuecomment-424542217) Tim 
>>> Graham raised the question of whether we should make sqlparse a mandatory 
>>> requirement for the sqlite tests or if we should skip those tests that 
>>> require it. In later discussion (
>>> https://github.com/django/django/pull/10406#issuecomment-427362983), 
>>> Tim raised the point that the introspection code is used by migrations.
>>>
>>> I'm not clear myself what the best route forwards here is, so I'm 
>>> bringing it to Django Developers for discussion (as Tim suggested). 
>>>
>>> Thanks,
>>> Ian
>>>
>>> -- 
>>> 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 https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/CAFv-zfKadOeWit8M6GMmx4H2ChUCU6u%3DscHX8F7oBKJkHRbuVg%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https:/