Re: Ticket #29015

[Adam Johnson]

It's a lot easier to review code changes if you submit a pull request, and
you'll get much more attention for a pull request with passing tests than
pasting a stack trace to the mailing list. Here's the how-to:
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/
. Also I find that by going through the review checklist I can often answer
my own questions.

Anyway my answers to your questions:

1. Probably
2. I don't think so, cf all the other exception messages from Django
3. Can you pull the limit from a PostgreSQL server variable? If it's not
easy then don't bother supporting that case, probably 0.01% of users
compile their own database server.

On 18 January 2018 at 05:42,  wrote:

> Hello !
>
> I have made a simple change to the django/db/backends/postgresql/base.py
> and added a NotSupportedError for the database-name. The result of the
> makemigrations command currently looks like this:
>
> Traceback (most recent call last):
>   File "manage.py", line 15, in 
> execute_from_command_line(sys.argv)
>   File "/home/priyansh/django/django/core/management/__init__.py", line
> 373, in execute_from_command_line
> utility.execute()
>   File "/home/priyansh/django/django/core/management/__init__.py", line
> 367, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/home/priyansh/django/django/core/management/base.py", line 288,
> in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/home/priyansh/django/django/core/management/base.py", line 335,
> in execute
> output = self.handle(*args, **options)
>   File 
> "/home/priyansh/django/django/core/management/commands/makemigrations.py",
> line 92, in handle
> loader.check_consistent_history(connection)
>   File "/home/priyansh/django/django/db/migrations/loader.py", line 274,
> in check_consistent_history
> applied = recorder.applied_migrations()
>   File "/home/priyansh/django/django/db/migrations/recorder.py", line 61,
> in applied_migrations
> if self.has_table():
>   File "/home/priyansh/django/django/db/migrations/recorder.py", line 44,
> in has_table
> return self.Migration._meta.db_table in self.connection.introspection.
> table_names(self.connection.cursor())
>   File "/home/priyansh/django/django/db/backends/base/base.py", line 255,
> in cursor
> return self._cursor()
>   File "/home/priyansh/django/django/db/backends/base/base.py", line 232,
> in _cursor
> self.ensure_connection()
>   File "/home/priyansh/django/django/db/backends/base/base.py", line 216,
> in ensure_connection
> self.connect()
>   File "/home/priyansh/django/django/db/backends/base/base.py", line 193,
> in connect
> conn_params = self.get_connection_params()
>   File "/home/priyansh/django/django/db/backends/postgresql/base.py",
> line 155, in get_connection_params
> "Database names longer than 63 characters are not supported by
> PostgreSQL. "
> django.db.utils.NotSupportedError: Database names longer than 63
> characters are not supported by PostgreSQL. Please supply a shorter NAME
> value in settings.DATABASES.
>
> However, there are some issues that I would like to address here.
>
> 1. Is the NotSupportedError appropriate here ?
> 2. Should there be a newline after "... supported by PostgreSQL." ?
> 3. From the info given at http://www.postgresql.org/
> docs/current/interactive/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS,
> it is possible to modify this default limit of 63 characters. However, this
> is to be done by hacking the source code and recompiling PostgreSQL. How
> should I handle the situation when this limit is modified in the PostgreSQL
> source-code ?
>
> Any advice, suggestion or comment would be really helpful :)
>
> Thanks !
> Priyansh
>
> --
> 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/8640611c-2114-4e10-aebc-
> 3bbe50b430a8%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 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/CAMyDDM2wZOPMR_W_1i-Ymq4fe%3DQdBHOOmH_Md_Wck

Re: Improving MSSQL and Azure SQL support on Django

[kunal . kabra]

Hi,

I am new to Django, but planning to use Django 2.0 for my newest project. I 
am using MSSQL db and hence facing issues with it.

Anyone working on getting an MSSQL backend that works with Django 2.0? 
(Couldn't find one that's up to date including django-pyodbc-azure).

Any help would be much appreciated.

Thanks,
Kunal

On Saturday, April 29, 2017 at 3:31:33 AM UTC+5:30, Michael Manfre wrote:
>
> Quick update of the current status of things related to MSSQL. The most 
> actively maintained MSSQL backend that I'm aware of is django-pyodbc-azure 
> (also works with standalone SQL Server). Michiya has been doing an amazing 
> job supporting that backend. There has been no real movement toward there 
> being an officially supported MSSQL backend for Django. Microsoft has 
> continued to be involved with Django and myself related to making a better 
> MSSQL experience for us.
>
> Regards,
> Michael Manfre
>
> On Fri, Apr 28, 2017 at 3:55 PM > wrote:
>
>> I wonder if there have been any updates on MS support for a 
>> official/supported MS SQL Django driver? Did the offered engineering effort 
>> from MS ever come through? Given the availability of of MS SQL on Linux, as 
>> well as support for Django in Visual Studio, it would be great if this came 
>> to fruition.
>> Explicit support for Django with IronPython would also be nice, if MS 
>> would really want to take their Django support to the next level...
>>
>>
>> On Monday, March 7, 2016 at 5:37:06 PM UTC-5, Meet Bhagdev wrote:
>>>
>>> Hi all,
>>>
>>> On interacting with several Django developers and committers, one of the 
>>> questions often came up, can I use SQL Server on non Window OS's? I wanted 
>>> to share that today Microsoft announced SQL Server availibility on Linux - 
>>> https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/
>>> . 
>>>
>>> While there is still work needed to strengthen the MSSQL-Django story, 
>>> we hope this aids more Linux developers to give SQL Server a shot. Let me 
>>> know of your thoughts and questions :)
>>>
>>> Cheers,
>>> Meet
>>>
>>> On Monday, February 22, 2016 at 4:54:38 PM UTC-8, Vin Yu wrote:

 Hey Folks, 

 My name is Vin and I work with Meet in the Microsoft SQL Server team. 
 Just wanted to let you all know we are still looking into how we can 
 better 
 improve and support MSSQL for the Django framework. We’ll continue to sync 
 with Michael and let you know of any updates soon. 

 Christiano and Tim - thanks for sharing your interest and sharing how 
 you are using Django with MSSQL. It's great to learn from your scenarios. 

 If you have any concerns, questions or comments feel free to reach out 
 to me at vinsonyu[at]microsoft.com
>>>
>>> -- 
>> 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/8258f170-8f10-45fc-a1d3-9551efca6d1c%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e1709320-49a0-47fd-8a92-87105db3ad43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ManytoMany Field save_form_data has not support for through table

[Andrew Standley]

Hi Collin,
  The patch seems to work perfectly with intermediate models without 
required fields. 

However looking over the pull request I noticed that there does not appears 
to be success tests for intermediate models with extra required fields.
Is this something I could help out with?

Cheers,
  Andrew

-- 
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/e5ca3a21-3f27-441c-a4cf-7a5ed9aa4f60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ManytoMany Field save_form_data has not support for through table

[Collin Anderson]

Hi Andrew,

Sure, do you want propose some tests? You could even open a new PR.

Thanks,
Collin
574-339-1060


On Thu, Jan 18, 2018 at 12:40 AM, Andrew Standley 
wrote:

> Hi Collin,
>   The patch seems to work perfectly with intermediate models without
> required fields.
>
> However looking over the pull request I noticed that there does not
> appears to be success tests for intermediate models with extra required
> fields.
> Is this something I could help out with?
>
> Cheers,
>   Andrew
>
> --
> 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/e5ca3a21-3f27-441c-a4cf-
> 7a5ed9aa4f60%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S7jdD8i%2BQirNTfKRTdLF%2Bf-6Lu-7k2L1asv3A7X%3Dsic_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if Object Provided

[Florian Apolloner]

On Thursday, January 18, 2018 at 2:55:27 AM UTC+1, Mehmet Dogan wrote:
>
> If that is the way forward, I will volunteer for the code. But, as you 
> also point out, there needs to be a *path* out. That I don't know :)
>

Personally I think it is (though I haven't had hours to think about it). 
That said, the backwards compat and migration has to be considered 
carefully.

Cheers,
Florian

-- 
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/823017b9-fa0e-47e7-be7d-034b892bc432%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if Object Provided

[Mehmet Dogan]

Andrew,

Yes, I think we can safely assume *apps *would be backend agnostic. I was
actually referring to the *backends *themselves, if they use
user.has_perm(...). This might sound counter-intuitive at first but I think
it is possible, and actually I am working on one right now (see my long
answer for details).

*Long Answer:* I am trying to write a Roles backend with, and without
reinventing the wheels for, object and model permissions. The logic is very
simple.

class Role(models.Model):
   delegate = models.OneToOneField(Permission,* ...*)
   perms = models.ManyToManyField(Permission, *...*)
*...*

Delegate is a permission for each role that lets a user use it, e.g.,
'roles.use_role_xx'; and the `perms` are the actual
permission in the Role. And my backend (pseudo code):

def has_perm(self, user_obj, perm, obj=None):
   if perm is delegate:
 ignore;

   delegates = get_delegates_representing(perm)

   for delegate in delegates:
  if user_obj.has_perm(delegate, obj):  # refer to existing other backends
 return True
   return False

1) Now, as seen above user_obj.has_perm(delegate, obj) is written for
the proposed way, and would not work with the current
way as model permissions would be excluded.

2) In order to prevent infinite loops, I have to strictly separate
permissions that represent Roles (namely delegates) and
permissions in the roles. If I could specify backends as I proposed
earlier, I could even take this even one step further
and allow roles include other roles (that would be awesome).

3) I have not tested or used this. And one might see it as a hairy design
to be disregarded. But I claim it has a fair chance to be
otherwise. *When it comes to backends we don't have plenty of choices, and
allowing them leverage each other will just make*
*it easier to write them. *

*Thanks for reading so far! :)*

On Wed, Jan 17, 2018 at 8:42 PM Andrew Standley <
astand...@linear-systems.com> wrote:

> Mehmet,
> Can you explain to me what the situation would be that an app could
> simply not be backend agnostic?
> Given that AUTHENTICATION_BACKENDS is a *user* configuration, it seems
> odd that an app would ever design around specific backends being installed.
> I'm not sure I follow your logic on this.
> Regarding an API that will allow picking and choosing I already have some
> ideas, but I think Carlton made an excellent point that that is another
> discussion all together.
>
> Cheers,
> Andrew
>
>
> On 1/17/2018 5:34 PM, Mehmet Dogan wrote:
>
> Andrew,
>
> Thank you for the input. Having options is good. My concern about that is,
> it may divide the already small backends population. If a backend relies on
> PermissionAuthorizationBackend, and another require the
> ModelOnlyPermissionAuthorizationBackend; then one cannot use both.
> Guardian, at its core, is agnostic of the default backend
> behavior, however, relies on it in some utilities. However, I am working on
> a simple RolePermissionsBackend now that leverages existing Object and
> Model backends at its core. Currently, if I do
> `user.has_perm('foo.change_bar')` or `user.has_perm('foo.change_bar', obj)`
> I know one is the model and the other is the object permissions. In case of
> plug-ins, that will go away, and it will be even harder to leverage
> existing backends. Also, the logic that polls backends is in
> auth/models.py, I do not see how would it be possible to design an API that
> will let picking and choosing.
>
> On Wed, Jan 17, 2018 at 12:58 PM Andrew Standley <
> astand...@linear-systems.com> wrote:
>
> Hi Carlton,
>> Thanks for the thoughts. I just wanted to share my opinion on your
>> options.
>>
>> 1. "Won't Fix"
>> I have yet to find anywhere the original design decisions were
>> documented. Based on what I can find, it appears that object level
>> permissions where a bit of an after-though for the initial auth framework.
>> Unless we can find the motivation for the original design decision it seems
>> foolish to leave *unexpected* behaviour simply because that's how it has
>> always been.
>>
>> I understand the motivation for wanting to only check object level
>> permissions, but I would argue that the design of the API insinuates a
>> hierarchical behaviour which is part of the reason the current behaviour is
>> unexpected.
>> Specifically why use an 'obj' kwarg instead of having two methods?
>>
>> To me if the API where:
>> ```
>> has_perm('foo.change_bar')
>> has_obj_perm('foo.change_bar', bar_obj)
>> ```
>> I would expect `has_perm` to only deal with model level permissions and
>> `has_obj_perm` to only deal with object level permissions
>>
>> To me the current API:
>> ```
>> has_perm('foo.change_bar', obj=bar_obj)
>> ```
>> Implies that the method will always check model level permissions and can
>> *optionally* check object level permissions.
>>
>> Having to always call `if user.has_perm('foo.change_bar', obj=bar) or
>> user.has_perm('foo.change_bar')` both seems ugly, and relie

Re: Default Authorization BackEnd Denying Permissions if Object Provided

[Mehmet Dogan]

For the migration, I think most sensible way is to *extend *the current
backend and provide it as an option, until the other is depreciated and
removed. This would act as a global setting in the meantime. But
eventually, I think, we should have just 1 default backend for the sake of
consistency overall. People can always extend it and put it above it in the
setting to alter default behavior, or just replace it, if they need.

But I would also like to point out one disadvantage of the new way: it will
make harder, and maybe impossible in some cases, to pull object permissions
over the common API. For example in the existing scheme:
user.has_perm('foo.change_bar') and user.has_perm('foo.change_bar', obj)
are two exclusive sets.  Easy to add if needed, however, in the new scheme,
the latter will include the former, and set subtraction will cause loss of
data if there was overlap (i.e., intersection was not empty). This (again)
will bring us back to specifying backends for control and flexibility.

On Thu, Jan 18, 2018 at 10:25 AM Mehmet Dogan  wrote:

> Andrew,
>
> Yes, I think we can safely assume *apps *would be backend agnostic. I was
> actually referring to the *backends *themselves, if they use
> user.has_perm(...). This might sound counter-intuitive at first but I think
> it is possible, and actually I am working on one right now (see my long
> answer for details).
>
> *Long Answer:* I am trying to write a Roles backend with, and without
> reinventing the wheels for, object and model permissions. The logic is very
> simple.
>
> class Role(models.Model):
>delegate = models.OneToOneField(Permission,* ...*)
>perms = models.ManyToManyField(Permission, *...*)
> *...*
>
> Delegate is a permission for each role that lets a user use it, e.g., 
> 'roles.use_role_xx'; and the `perms` are the actual
> permission in the Role. And my backend (pseudo code):
>
> def has_perm(self, user_obj, perm, obj=None):
>if perm is delegate:
>  ignore;
>
>delegates = get_delegates_representing(perm)
>
>for delegate in delegates:
>   if user_obj.has_perm(delegate, obj):  # refer to existing other backends
>  return True
>return False
>
> 1) Now, as seen above user_obj.has_perm(delegate, obj) is written for the 
> proposed way, and would not work with the current
> way as model permissions would be excluded.
>
> 2) In order to prevent infinite loops, I have to strictly separate
> permissions that represent Roles (namely delegates) and
> permissions in the roles. If I could specify backends as I proposed
> earlier, I could even take this even one step further
> and allow roles include other roles (that would be awesome).
>
> 3) I have not tested or used this. And one might see it as a hairy design
> to be disregarded. But I claim it has a fair chance to be
> otherwise. *When it comes to backends we don't have plenty of choices,
> and allowing them leverage each other will just make*
> *it easier to write them. *
>
> *Thanks for reading so far! :)*
>
> On Wed, Jan 17, 2018 at 8:42 PM Andrew Standley <
> astand...@linear-systems.com> wrote:
>
>> Mehmet,
>> Can you explain to me what the situation would be that an app could
>> simply not be backend agnostic?
>> Given that AUTHENTICATION_BACKENDS is a *user* configuration, it seems
>> odd that an app would ever design around specific backends being installed.
>> I'm not sure I follow your logic on this.
>> Regarding an API that will allow picking and choosing I already have some
>> ideas, but I think Carlton made an excellent point that that is another
>> discussion all together.
>>
>> Cheers,
>> Andrew
>>
>>
>> On 1/17/2018 5:34 PM, Mehmet Dogan wrote:
>>
>> Andrew,
>>
>> Thank you for the input. Having options is good. My concern about that
>> is, it may divide the already small backends population. If a backend
>> relies on PermissionAuthorizationBackend, and another require the
>> ModelOnlyPermissionAuthorizationBackend; then one cannot use both.
>> Guardian, at its core, is agnostic of the default backend
>> behavior, however, relies on it in some utilities. However, I am working on
>> a simple RolePermissionsBackend now that leverages existing Object and
>> Model backends at its core. Currently, if I do
>> `user.has_perm('foo.change_bar')` or `user.has_perm('foo.change_bar', obj)`
>> I know one is the model and the other is the object permissions. In case of
>> plug-ins, that will go away, and it will be even harder to leverage
>> existing backends. Also, the logic that polls backends is in
>> auth/models.py, I do not see how would it be possible to design an API that
>> will let picking and choosing.
>>
>> On Wed, Jan 17, 2018 at 12:58 PM Andrew Standley <
>> astand...@linear-systems.com> wrote:
>>
>> Hi Carlton,
>>> Thanks for the thoughts. I just wanted to share my opinion on your
>>> options.
>>>
>>> 1. "Won't Fix"
>>> I have yet to find anywhere the original design decisions were
>>> documented. Based on what 

PR 9583 - Ticket 28643

[Matthew Pava]

Hi everyone,
I've been working on ticket 28643 specifically adding Ord, Chr, Left, and Right 
to Django's built-in database functions.  I've done the PR #9583.  I am a new 
contributor, and I've never really contributed code to any project through pull 
requests ever before.  I appreciate your guidance.  The checks have passed, and 
I've got a mess of commits that I've tried to squash a couple of times but seem 
to stick around nonetheless.

I also made a comment on the ticket that maybe instead of using Left, Right, 
and Substr functions that we instead implement slicing on fields and 
expressions to make things more pythonic (and deprecate Left, Right, and 
Substr).  Would such an implementation need a new ticket?  And then would we 
need to consider slicing all iterables instead of just only CharFields, 
TextFields, and string expressions?

Also, most of the functions in ticket 28643 that go across all supported Django 
database backends are complete, with the exception of ROUND.  SQLite does not 
come with many built-in math functions, though there are extensions available.  
I was wondering how we should proceed with that ticket when ROUND is completed.

Thank you!

https://github.com/django/django/pull/9583
https://code.djangoproject.com/ticket/28643

-- 
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/08256bba55da406080bdc813ef776c29%40ISS1.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket #29015

[askpriyansh]

Hello Adam !

I created a PR as per your suggestion, and updated the ticket with the 'has 
patch' flag. Please review the patch, and do give your suggestions.

Thanks !
Priyansh

-- 
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/7bb2be66-a9e9-4450-a52e-970138f2bfa6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default Authorization BackEnd Denying Permissions if Object Provided

[Andrew Standley]

Hey Mehmet,

If a backend relies on PermissionAuthorizationBackend, and another 
require the ModelOnlyPermissionAuthorizationBackend
    So I think this is the point that confuses me. Why you would use 
the user API if you cared about a specific backend?


Using your example of the RolesBackend, either
A) You want to leave it up to the user whether a role grants object 
level permissions or not.

B) You want to have consistent behavior for your backend.

Explanation:

A) In this case you would use your pseudo code example.
To return true (proposed) for an object when a user has the model level 
permission (ie a role with this permission) the user would configure 
their setting so

```
AUTHENTICATION_BACKENDS = [
    'PermissionAuthorizationBackend',
    'RolesBackend',
]
```
To return false (current) for an object when a user has the model level 
permission the user would configure their setting so

```
AUTHENTICATION_BACKENDS = [
    'ModelOnlyPermissionAuthorizationBackend',
    'RolesBackend',
]
```
In either case the backend order does not particularly matter for this 
example.


B) In this case the backend should derive or call the backend whose 
behaviour it requires.

```
class RolesBackend(PermissionAuthorizationBackend):
    def has_perm(self, user_obj, perm, obj=None):
    ...
    for delegate in delegates:
  if super(RolesBackend, self).has_perm(user_obj, perm, obj):
  return True
   return False
```

Cheers,
    Andrew


On 1/18/2018 8:25 AM, Mehmet Dogan wrote:

Andrew,

Yes, I think we can safely assume *apps *would be backend agnostic. I 
was actually referring to the *backends *themselves, if they use 
user.has_perm(...). This might sound counter-intuitive at first but I 
think it is possible, and actually I am working on one right now (see 
my long answer for details).


_Long Answer:_ I am trying to write a Roles backend with, and without 
reinventing the wheels for, object and model permissions. The logic is 
very simple.

class Role(models.Model):
delegate = models.OneToOneField(Permission,*...*)
perms = models.ManyToManyField(Permission,*...*)
 *...*
Delegate is a permission for each role that lets a user use it, e.g., 
'roles.use_role_xx'; and the `perms` are the actual permission in 
the Role. And my backend (pseudo code):

def has_perm(self, user_obj, perm, obj=None):
if perm is delegate:
  ignore;
delegates = get_delegates_representing(perm)
for delegatein delegates:
   if user_obj.has_perm(delegate, obj):# refer to existing other backends 
return True return False
1) Now, as seen aboveuser_obj.has_perm(delegate, obj)is written for 
the proposed way, and would not work with the current way as model 
permissions would be excluded.
2) In order to prevent infinite loops, I have to strictly separate 
permissions that represent Roles (namely delegates) and
permissions in the roles. If I could specify backends as I proposed 
earlier, I could even take this even one step further

and allow roles include other roles (that would be awesome).

3) I have not tested or used this. And one might see it as a hairy 
design to be disregarded. But I claim it has a fair chance to be
otherwise. /*When it comes to backends we don't have plenty of 
choices, and allowing them leverage each other will just make*/

/*it easier to write them. */

/Thanks for reading so far! :)/

On Wed, Jan 17, 2018 at 8:42 PM Andrew Standley 
mailto:astand...@linear-systems.com>> 
wrote:


Mehmet,
    Can you explain to me what the situation would be that an app
could simply not be backend agnostic?
Given that AUTHENTICATION_BACKENDS is a /user/ configuration, it
seems odd that an app would ever design around specific backends
being installed. I'm not sure I follow your logic on this.

Regarding an API that will allow picking and choosing I already
have some ideas, but I think Carlton made an excellent point that
that is another discussion all together.

Cheers,
    Andrew


On 1/17/2018 5:34 PM, Mehmet Dogan wrote:

Andrew,

Thank you for the input. Having options is good. My concern about
that is, it may divide the already small backends population. If
a backend relies on PermissionAuthorizationBackend, and another
require the ModelOnlyPermissionAuthorizationBackend; then one
cannot use both. Guardian, at its core, is agnostic of the
default backend behavior, however, relies on it in some
utilities. However, I am working on a simple
RolePermissionsBackend now that leverages existing Object and
Model backends at its core. Currently, if I do
`user.has_perm('foo.change_bar')` or
`user.has_perm('foo.change_bar', obj)` I know one is the model
and the other is the object permissions. In case of plug-ins,
that will go away, and it will be even harder to leverage
existing backends. Also, the logic that polls backends is in
auth/models.py, 

RE: Default Authorization BackEnd Denying Permissions if ObjectProvided

[Mehmet Dogan]

Andrew,

> Why you would use the user API if you cared about a specific backend?

True. I wouldn’t. 

> Using your example of the RolesBackend, either 
> A) You want to leave it up to the user whether a role grants object level 
> permissions or not.
> B) You want to have consistent behavior for your backend. 

Seemed like I wanted consistent behavior without relying on any particular 
backend. But, I see this restricts the design choices elsewhere or for others. 
Whether advantages outweigh disadvantages, or vice versa, I am not sure. 

I was envisioning that one who uses multiple backends, say at least 3, would 
get everything needed through the common API, as well as seamless reusability 
of backends within each other. 

But your scenario B gave me some ideas for backup. Thanks 😊

Mehmet

From: Andrew Standley
Sent: Thursday, January 18, 2018 1:29 PM
To: django-developers@googlegroups.com
Subject: Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

Hey Mehmet,
If a backend relies on PermissionAuthorizationBackend, and another require the 
ModelOnlyPermissionAuthorizationBackend
    So I think this is the point that confuses me. Why you would use the user 
API if you cared about a specific backend?

Using your example of the RolesBackend, either 
A) You want to leave it up to the user whether a role grants object level 
permissions or not.
B) You want to have consistent behavior for your backend. 

Explanation:

A) In this case you would use your pseudo code example. 
To return true (proposed) for an object when a user has the model level 
permission (ie a role with this permission) the user would configure their 
setting so
```
AUTHENTICATION_BACKENDS = [
    'PermissionAuthorizationBackend',
    'RolesBackend',
]
```
To return false (current) for an object when a user has the model level 
permission the user would configure their setting so
```
AUTHENTICATION_BACKENDS = [
    'ModelOnlyPermissionAuthorizationBackend',
    'RolesBackend',
]
```
In either case the backend order does not particularly matter for this example.

B) In this case the backend should derive or call the backend whose behaviour 
it requires.
```
class RolesBackend(PermissionAuthorizationBackend):
    def has_perm(self, user_obj, perm, obj=None):
    ...
    for delegate in delegates:
  if super(RolesBackend, self).has_perm(user_obj, perm, obj):
  return True
   return False
```

Cheers,
    Andrew

-- 
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/5a60fdc2.c91b9d0a.50b0.7583%40mx.google.com.
For more options, visit https://groups.google.com/d/optout.

RE: Default Authorization BackEnd Denying Permissions ifObjectProvided

[Mehmet Dogan]

Andrew,

After further thought I came to think that, even if multiple options kept in 
the framework forever, the disadvantages will not be considerable. I still 
think it will limit inter-changeability (what is the word for this?), but most 
people/backends would follow the one that makes more sense, so it will should 
not be an issue. 

Sent from Mail for Windows 10

From: Mehmet Dogan
Sent: Thursday, January 18, 2018 2:04 PM
To: django-developers@googlegroups.com
Subject: RE: Default Authorization BackEnd Denying Permissions ifObjectProvided

Andrew,

> Why you would use the user API if you cared about a specific backend?

True. I wouldn’t. 

> Using your example of the RolesBackend, either 
> A) You want to leave it up to the user whether a role grants object level 
> permissions or not.
> B) You want to have consistent behavior for your backend. 
Seemed like I wanted consistent behavior without relying on any particular 
backend. But, I see this restricts the design choices elsewhere or for others. 
Whether advantages outweigh disadvantages, or vice versa, I am not sure. 

I was envisioning that one who uses multiple backends, say at least 3, would 
get everything needed through the common API, as well as seamless reusability 
of backends within each other. 

But your scenario B gave me some ideas for backup. Thanks 😊

Mehmet

From: Andrew Standley
Sent: Thursday, January 18, 2018 1:29 PM
To: django-developers@googlegroups.com
Subject: Re: Default Authorization BackEnd Denying Permissions if ObjectProvided

Hey Mehmet,
If a backend relies on PermissionAuthorizationBackend, and another require the 
ModelOnlyPermissionAuthorizationBackend
    So I think this is the point that confuses me. Why you would use the user 
API if you cared about a specific backend?

Using your example of the RolesBackend, either 
A) You want to leave it up to the user whether a role grants object level 
permissions or not.
B) You want to have consistent behavior for your backend. 

Explanation:

A) In this case you would use your pseudo code example. 
To return true (proposed) for an object when a user has the model level 
permission (ie a role with this permission) the user would configure their 
setting so
```
AUTHENTICATION_BACKENDS = [
    'PermissionAuthorizationBackend',
    'RolesBackend',
]
```
To return false (current) for an object when a user has the model level 
permission the user would configure their setting so
```
AUTHENTICATION_BACKENDS = [
    'ModelOnlyPermissionAuthorizationBackend',
    'RolesBackend',
]
```
In either case the backend order does not particularly matter for this example.

B) In this case the backend should derive or call the backend whose behaviour 
it requires.
```
class RolesBackend(PermissionAuthorizationBackend):
    def has_perm(self, user_obj, perm, obj=None):
    ...
    for delegate in delegates:
  if super(RolesBackend, self).has_perm(user_obj, perm, obj):
  return True
   return False
```

Cheers,
    Andrew


-- 
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/5a610980.8a40ca0a.70bfa.42b3%40mx.google.com.
For more options, visit https://groups.google.com/d/optout.

Re: PR 9583 - Ticket 28643

[charettes]

Hey Matthew,

I could see adding support for F('field')[0:5] being useful and more 
intuitive
than using Left/Right/Substr. You should be able to assert the field is 
sliceable
(e.g. an instance of CharField/TextField) in the expression returned by
F.__getitem__ (e.g. Left/Right/Substr) resolve_expression method.

Maybe having a F.__getitem__ return an intermediary Expression subclass
(e.g. FieldSlice) that resolves to the correct expression based on the type 
of
the sliced field and the nature of the slice in resolve_expression would 
work
better here.

I could see this having great benefit for usage with nested data structure 
fields
such as contrib.postgres ArrayField (e.g F('array')[0:10]) and JSONField 
where
we would finally have a way to specify a key without colliding with the 
builtin
lookups (e.g. F('data')['exact'], F('data')['exact'][0:10]).

That might be bit too much for this ticket though and you might want to only
focus on adding Left/Right/Substr for now.

Best,
Simon


Le jeudi 18 janvier 2018 13:06:29 UTC-5, matthew.pava a écrit :
>
> Hi everyone,
>
> I’ve been working on ticket 28643 specifically adding Ord, Chr, Left, and 
> Right to Django’s built-in database functions.  I’ve done the PR #9583.  I 
> am a new contributor, and I’ve never really contributed code to any project 
> through pull requests ever before.  I appreciate your guidance.  The checks 
> have passed, and I’ve got a mess of commits that I’ve tried to squash a 
> couple of times but seem to stick around nonetheless.
>
>  
>
> I also made a comment on the ticket that maybe instead of using Left, 
> Right, and Substr functions that we instead implement slicing on fields and 
> expressions to make things more pythonic (and deprecate Left, Right, and 
> Substr).  Would such an implementation need a new ticket?  And then would 
> we need to consider slicing all iterables instead of just only CharFields, 
> TextFields, and string expressions?
>
>  
>
> Also, most of the functions in ticket 28643 that go across all supported 
> Django database backends are complete, with the exception of ROUND.  SQLite 
> does not come with many built-in math functions, though there are 
> extensions available.  I was wondering how we should proceed with that 
> ticket when ROUND is completed.
>
>  
>
> Thank you!
>
>  
>
> https://github.com/django/django/pull/9583
>
> https://code.djangoproject.com/ticket/28643
>
>  
>

-- 
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/98353d57-9274-4738-baca-1754b6354d02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PR 9583 - Ticket 28643

[Josh Smeaton]

I think having Left/Right is the right way to go. If there are 
opportunities to use slicing syntax, then they would resolve internally to 
those Expressions I would think. But that can be done separately, and have 
greater scope such as ArrayField in Simons example.

On Friday, 19 January 2018 08:21:57 UTC+11, charettes wrote:
>
> Hey Matthew,
>
> I could see adding support for F('field')[0:5] being useful and more 
> intuitive
> than using Left/Right/Substr. You should be able to assert the field is 
> sliceable
> (e.g. an instance of CharField/TextField) in the expression returned by
> F.__getitem__ (e.g. Left/Right/Substr) resolve_expression method.
>
> Maybe having a F.__getitem__ return an intermediary Expression subclass
> (e.g. FieldSlice) that resolves to the correct expression based on the 
> type of
> the sliced field and the nature of the slice in resolve_expression would 
> work
> better here.
>
> I could see this having great benefit for usage with nested data structure 
> fields
> such as contrib.postgres ArrayField (e.g F('array')[0:10]) and JSONField 
> where
> we would finally have a way to specify a key without colliding with the 
> builtin
> lookups (e.g. F('data')['exact'], F('data')['exact'][0:10]).
>
> That might be bit too much for this ticket though and you might want to 
> only
> focus on adding Left/Right/Substr for now.
>
> Best,
> Simon
>
>
> Le jeudi 18 janvier 2018 13:06:29 UTC-5, matthew.pava a écrit :
>>
>> Hi everyone,
>>
>> I’ve been working on ticket 28643 specifically adding Ord, Chr, Left, and 
>> Right to Django’s built-in database functions.  I’ve done the PR #9583.  I 
>> am a new contributor, and I’ve never really contributed code to any project 
>> through pull requests ever before.  I appreciate your guidance.  The checks 
>> have passed, and I’ve got a mess of commits that I’ve tried to squash a 
>> couple of times but seem to stick around nonetheless.
>>
>>  
>>
>> I also made a comment on the ticket that maybe instead of using Left, 
>> Right, and Substr functions that we instead implement slicing on fields and 
>> expressions to make things more pythonic (and deprecate Left, Right, and 
>> Substr).  Would such an implementation need a new ticket?  And then would 
>> we need to consider slicing all iterables instead of just only CharFields, 
>> TextFields, and string expressions?
>>
>>  
>>
>> Also, most of the functions in ticket 28643 that go across all supported 
>> Django database backends are complete, with the exception of ROUND.  SQLite 
>> does not come with many built-in math functions, though there are 
>> extensions available.  I was wondering how we should proceed with that 
>> ticket when ROUND is completed.
>>
>>  
>>
>> Thank you!
>>
>>  
>>
>> https://github.com/django/django/pull/9583
>>
>> https://code.djangoproject.com/ticket/28643
>>
>>  
>>
>

-- 
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/af172482-ffb2-4b0c-ba2f-5f16e876302c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PR 9583 - Ticket 28643

[Adam Johnson]

+1 for adding Left/Right as plain functions right now.

Simon's example for a new future is really nice but outside the scope of
the ticket.

On 18 January 2018 at 22:30, Josh Smeaton  wrote:

> I think having Left/Right is the right way to go. If there are
> opportunities to use slicing syntax, then they would resolve internally to
> those Expressions I would think. But that can be done separately, and have
> greater scope such as ArrayField in Simons example.
>
>
> On Friday, 19 January 2018 08:21:57 UTC+11, charettes wrote:
>>
>> Hey Matthew,
>>
>> I could see adding support for F('field')[0:5] being useful and more
>> intuitive
>> than using Left/Right/Substr. You should be able to assert the field is
>> sliceable
>> (e.g. an instance of CharField/TextField) in the expression returned by
>> F.__getitem__ (e.g. Left/Right/Substr) resolve_expression method.
>>
>> Maybe having a F.__getitem__ return an intermediary Expression subclass
>> (e.g. FieldSlice) that resolves to the correct expression based on the
>> type of
>> the sliced field and the nature of the slice in resolve_expression would
>> work
>> better here.
>>
>> I could see this having great benefit for usage with nested data
>> structure fields
>> such as contrib.postgres ArrayField (e.g F('array')[0:10]) and JSONField
>> where
>> we would finally have a way to specify a key without colliding with the
>> builtin
>> lookups (e.g. F('data')['exact'], F('data')['exact'][0:10]).
>>
>> That might be bit too much for this ticket though and you might want to
>> only
>> focus on adding Left/Right/Substr for now.
>>
>> Best,
>> Simon
>>
>>
>> Le jeudi 18 janvier 2018 13:06:29 UTC-5, matthew.pava a écrit :
>>>
>>> Hi everyone,
>>>
>>> I’ve been working on ticket 28643 specifically adding Ord, Chr, Left,
>>> and Right to Django’s built-in database functions.  I’ve done the PR
>>> #9583.  I am a new contributor, and I’ve never really contributed code to
>>> any project through pull requests ever before.  I appreciate your
>>> guidance.  The checks have passed, and I’ve got a mess of commits that I’ve
>>> tried to squash a couple of times but seem to stick around nonetheless.
>>>
>>>
>>>
>>> I also made a comment on the ticket that maybe instead of using Left,
>>> Right, and Substr functions that we instead implement slicing on fields and
>>> expressions to make things more pythonic (and deprecate Left, Right, and
>>> Substr).  Would such an implementation need a new ticket?  And then would
>>> we need to consider slicing all iterables instead of just only CharFields,
>>> TextFields, and string expressions?
>>>
>>>
>>>
>>> Also, most of the functions in ticket 28643 that go across all supported
>>> Django database backends are complete, with the exception of ROUND.  SQLite
>>> does not come with many built-in math functions, though there are
>>> extensions available.  I was wondering how we should proceed with that
>>> ticket when ROUND is completed.
>>>
>>>
>>>
>>> Thank you!
>>>
>>>
>>>
>>> https://github.com/django/django/pull/9583
>>>
>>> https://code.djangoproject.com/ticket/28643
>>>
>>>
>>>
>> --
> 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/af172482-ffb2-4b0c-ba2f-
> 5f16e876302c%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 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/CAMyDDM36i7t6wZ6P3X%2BoQ3vzYhfUyW2Kt4ym%2BwQjX5Ph7aypSQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket #29015

[askpriyansh]

Hello !

I updated the PR as per your comments, and I have run into the problem of 
failing checks, while they run fine on my system. I have fixed the problem of 
flake8 build-failure. However, I am unable to resolve the issue of 
ImportFailure of psycopg2.

Is it because of some environment changes that I have to accommodate ? Do I 
need to supply more information about this ?

Thanks !
Priyansh

-- 
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/70b08dd4-acef-4f53-8b83-559f880d5aed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.