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-pat
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
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,
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 t
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).
Th
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 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 ove
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 guid
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 Dja
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, e
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 yo
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 sen
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_exp
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:
+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, th
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 change
16 matches
Mail list logo
