Yeah, that’s a good point Michal.
On Sat, Aug 27, 2016 at 1:14 PM Michal Petrucha <
michal.petru...@konk.org> wrote:
> On August 27, 2016 5:48:26 PM GMT+02:00, Paulo Gabriel Poiati <
> paulogpoi...@gmail.com> wrote:
> >Hello Aymeric,
> >
> >I think you
directly” pattern.
Thank you!
On Sat, Aug 27, 2016 at 9:18 AM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello,
>
> > On 27 Aug 2016, at 00:57, Paulo Gabriel Poiati
> wrote:
> >
> > What if we allow the change of the default manager of all m
Hello,
I’m not sure if this have been discussed here already. I didn’t find
anything in Tracker.
What if we allow the change of the default manager of all models? This
could be done through the settings, something like DEFAULT_MODEL_MANAGER.
Examples of use cases are:
- Change the `create` meth
That is because the documentation is referring to the WSGI envrion
dictionary (and thus the CGI spec). This is how the translation from the
client to the server works: X-My-Header becomes HTTP_X_MY_HEADER. It isn't
wrong IMO.
On Sun, Jun 5, 2016 at 8:52 AM Vignesh Tnj wrote:
> https://docs.djang
Hello,
I would like some help from the core guys. I'm getting an error while
executing the following query (the objective of this query is basically get
the last created employee for each company):
*Company.objects.annotate(Max('employee__pk')).filter(employee__pk=F('employee__pk__max'))*
The er
Very handy +1.
--
[]'s
Paulo Poiati
blog.paulopoiati.com
On Tue, Sep 22, 2015 at 9:09 PM Russell Keith-Magee
wrote:
> On Wed, Sep 23, 2015 at 7:06 AM, Josh Smeaton
> wrote:
> >> Could we have permanent backward-compatible (no deprecation timeline)
> >> shims? I'm -0 if not because it's yet-ano
On Sat, May 23, 2015 at 3:38 PM Carl Meyer wrote:
> On 05/23/2015 11:37 AM, Marc Tamlyn wrote:
> > If the backend is inferred by a single value in the settings and not
> > stored alongside the user ID, what would happen to existing users
> > who are already logged in when a second bac
sn't, the client needs to provide one explicitly.
On Fri, May 22, 2015 at 5:07 PM Carl Meyer wrote:
> Hi Paulo,
>
> On 05/22/2015 01:49 PM, Paulo Gabriel Poiati wrote:
> > I understand your points Carl, but I'm more inclined to think about the
> > average django developer
I understand your points Carl, but I'm more inclined to think about the
average django developer and the new comers. Most people don't know or
don't want to know what an Authentication Backend is, they just want to
write their app. That is why I don't like exposing this kind of detail in
the client
te a user without logging them in?
>
> On Fri, May 22, 2015 at 8:57 AM, Paulo Gabriel Poiati <
> paulogpoi...@gmail.com> wrote:
>
>> Maybe this is not the perfect example because we have the plain password
>> in the form. Another one is if a backoffice user can log as an
Maybe this is not the perfect example because we have the plain password in
the form. Another one is if a backoffice user can log as any user of the
system.
On Fri, May 22, 2015 at 12:53 PM Paulo Gabriel Poiati <
paulogpoi...@gmail.com> wrote:
> Of course Tim,
>
> One instance is
Of course Tim,
One instance is if you need to login the user after registration:
class RegistrationView(CreateView):
...
def form_valid(self, form):
user = form.save()
login(self.request, user)
# redirect
I don't have the user password because it's an one way has
Hello guys,
I want to discuss the current login workflow in django. As it is we need to
call `authenticate` before `login` because we need to set the
authentication backend in the user model. We can use login without
authenticate if we set the backend attr manually, but this need some
implementati
The problem with CBV is the learning curve. You can do standard things like
CRUD's fast as hell but if you need some kind of customisation you probably
gonna need to deep dive into the class hierarchy to understand it. If you
dominate it you will be very productive and happy.
I'm not saying there
14 matches
Mail list logo
