Re: Global access to request.user

On Wed, Apr 1, 2015 at 3:43 AM, Thomas Güttler wrote: > Headache makes the code which gets called outside the request-response > cycle. > For example cron jobs. > > Example: We create reports for users in cron jobs. Here we need a user > object > and have no context. You still

Re: Global access to request.user

On Wed, Apr 1, 2015 at 9:36 AM, Thomas Güttler wrote: > Am 27.03.2015 um 17:16 schrieb Cal Leeming: >> >> Hmm this all sounds quite dirty :/ >> >> However if you absolutely want to have a global object, you could try >> something like [1], although I don't recommend it at all.

Re: Global access to request.user

Am 27.03.2015 um 19:05 schrieb Stephen J. Butler: On Fri, Mar 27, 2015 at 10:30 AM, Thomas Güttler wrote: You have an instance method to render one row of a search result (a custom paginator). One column of this row displays a link. Some users are allowed to follow the

Re: Global access to request.user

Am 27.03.2015 um 17:16 schrieb Cal Leeming: Hmm this all sounds quite dirty :/ However if you absolutely want to have a global object, you could try something like [1], although I don't recommend it at all. There are some situations where your modelling needs request introspection, for example

Re: Global access to request.user

On Fri, Mar 27, 2015 at 10:30 AM, Thomas Güttler wrote: > You have an instance method to render one row of a search result (a custom > paginator). > > One column of this row displays a link. Some users are allowed to follow the > link, > some are not. You need to check the (row

Re: Global access to request.user

Hmm this all sounds quite dirty :/ However if you absolutely want to have a global object, you could try something like [1], although I don't recommend it at all. There are some situations where your modelling needs request introspection, for example row level auditing, but these are very

Re: Global access to request.user

Am 27.03.2015 um 15:49 schrieb Cal Leeming: There is a reason that state is passed around from method to method, rather than being stored as a global, because this is the correct way to do things. Is a threadlocal global state part of the correct way, or is it "evil"? However, it sounds

Re: Global access to request.user

There is a reason that state is passed around from method to method, rather than being stored as a global, because this is the correct way to do things. However, it sounds like the architectural design of your code is flawed, as throwing around the request object indicates that you don't have

Re: Global access to request.user

Other way is use sessions! Django provide session midleware. You can get the session dict out of the view! Sorry my english, I am a Brazilian guy! > > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop

Re: Global access to request.user

Maybe a global state? Yes! https://docs.djangoproject.com/en/1.7/topics/http/middleware/#init I never did that, but you can try! -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from

Re: Global access to request.user

I don't understand how middlware or filter would help on those cases. Why not only pass the variable where it's needed? On Fri 27 Mar 2015 at 10:18 guettli wrote: > > > Am Donnerstag, 26. März 2015 15:52:07 UTC+1 schrieb Anderson Resende: >> >> You can use middlewares!!! It is

Re: Global access to request.user

Am Donnerstag, 26. März 2015 15:52:07 UTC+1 schrieb Anderson Resende: > > You can use middlewares!!! It is a way... > > > I don't understand how middleware can help here. The only way I see is that the middleware updates a global variable for the data. In my case request.user. Anderson, is

Re: Global access to request.user

I agree with Anderson, this is one solution, even though I don't know if it's a good way. For example a middleware is used to add the user to the request. You could do the same with the request to a singleton instance and get it back then from your form, view etc.? But be aware that some

Re: Global access to request.user

I don't see how middleware could be used to avoid passing the user or request parameter to the inner methods. As this is part of the view, I'd probably write a custom filter or tag, I dunno. Regards, Esau. On Thu, Mar 26, 2015 at 2:52 PM, Anderson Resende wrote: >

Re: Global access to request.user

You can use middlewares!!! It is a way... -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group,

Global access to request.user

I have a large legacy application which passes around the request to nearly every method. Reading this source is no fun. In about 95% of all cases "request" is not used, but "request.user" is needed for permission checking. Example: there is a drop down box with the list of possible actions