Re: Default Authorization BackEnd Denying Permissions if Object Provided

Based on this patch: the following 3 methods in the custom authorization backends will have to admit a *fallback_to_model *keyword argument: *def *has_perm(self, user_obj, perm, obj=None, fallback_to_model=None) def get_group_permissions(self, user_obj, obj=None, fallback_to_model=None) def

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Here is a sample patch: https://github.com/doganmeh/django/commit/d85cd3a530984ab5e4cb42f93629a64eb0b65b07 -- 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

Re: Should ModelField.choices accept a callable?

Migrations are mainly for tracking database changes. Model attributes not SQL related are pushed into the migrations also, presumably for the purposes of data migrations (maybe post-hoc justification, only a few people would actually know). Providing a callable still provides access to the

Re: Should ModelField.choices accept a callable?

Is "accept a callable" the best solution for everywhere this problem occurs? For example, same thing was proposed in "FileField storage param should allow a callable" (#28184). It seems a bit odd to me that on the one hand we say that we need to track changes to all model field attributes, but

Should ModelField.choices accept a callable?

https://code.djangoproject.com/ticket/22837 was closed as invalid. It concerns itself with migrations being detected when model field choices (which may be dynamic) change. The workaround suggested is to pass a callable to choices with a link to https://code.djangoproject.com/ticket/13181.

Re: Change Local Memory Cache to Use LRU #28977

Yup, good analysis, good numbers, thanks for running those. I'm happy with those results and think we should proceed. On Thursday, 11 January 2018 05:11:56 UTC+11, Adam Johnson wrote: > > Grant, you're a star. I think the tradeoff is acceptable too. > > On 10 January 2018 at 17:05, Grant Jenks

Re: Default Authorization BackEnd Denying Permissions if Object Provided

And the other: Here is what I propose in terms of working around the backward compatibility that seems to have kept it from being solved for so long. 1) define a global setting, say: OBJECT_PERMISSION_FALLBACK_TO_MODEL=False. This is to help maintain the default behavior (unless the setting

Re: Default Authorization BackEnd Denying Permissions if Object Provided

Here is the text of linked stuff for convenience: For authorization backends checking object level permissions (like guardian) usually requires calling the django's default authorization backend as a fallback to the more general set of permissions: if user.has_perm('foo.change_bar', obj=bar)

Default Authorization BackEnd Denying Permissions if Object Provided

Hello all, I had opened a ticket re issue noted in subject, which happened to be a duplicate, anyways, the text is here : Tim Graham told that it needs to be discussed here. Seems this is a long going issue, with several related issues

django CMS 3.5 Release Candidate 1

Hi everyone. We've just issued the first release candidate version of django CMS 3.5. It's available from all the usual places: GitHub: Download: Documentation:

Re: improving our Contributor License Agreement process

On Thursday, 11 January 2018 18:01:23 UTC+1, Marc Tamlyn wrote: > > But I don't think we need to enforce it for any contribution. > OK. I think that's the key. If that's the view then we can go on as is. Thanks all.  C. -- You received this message because you are subscribed to the

Re: improving our Contributor License Agreement process

Accessibility of contributing > Leal protection We shouldn't drop the idea of CLAs, they're there so that an organisation or individual who wants to do things "properly" can still do so. But I don't think we need to enforce it for any contribution. The CLA story for Django is already hazy, as we

Re: improving our Contributor License Agreement process

Hey Tim. > It sounds like you have the enthusiasm for this that I had in 2014. ;-) Yeah. What I liked was that your proposal was like a "I've actually thought about this" version of what I was beginning to ponder myself. :-) I don't really think we should drop the CLAs. It's just that if

Re: improving our Contributor License Agreement process

Hi Carlton, It sounds like you have the enthusiasm for this that I had in 2014. ;-) You could contact the DSF board if you want to try to get them to consult a lawyer about the necessity of CLAs. I guess opinions might vary from lawyer to lawyer. Given that Django has been operating for about

Re: improving our Contributor License Agreement process

I started reviewing patches according to the check-list this morning and, for first-time contributors, I was wondering how to validate the CLA status. Tim pointed me here. There is now (what looks like) a viable third-party provider: https://cla-assistant.io Amongst others, Microsoft use

Re: #28975 - Skip automatic creation of postgis extension if it already exists

On Wed, Jan 10, 2018 at 3:12 AM, Niclas Kron wrote: > Hello, > I am writing to you to establish some sort of consensus on how to proceed > with this bug/PR: > > * PR https://github.com/django/django/pull/9518 > * BUG https://code.djangoproject.com/ticket/28975 > > With