Django Web Framework: The 'D' is silent dumbass

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass

«‹›122 »

PT6A: Jan 5, 2006; Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane

Are there any situations where Django will send e-mails to users as a result of a failed login? A user has asked about it, without forwarding the e-mail in question, and I'm trying to figure out whether it's something that Django is doing on its own or something that one of clients is doing of their own volition.

As far as I can tell, correct me if I'm wrong, Django does not, on its own, send out any form of unsolicited email to users, but I just want to be sure since now I'm hearing about this from my clients and their users, all without any details (since that would just make my life TOO easy).

# ? Apr 7, 2015 06:14

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 08:00

Data Graham: Dec 28, 2009; 📈📊🍪😋

Do you have access to the server's outgoing mail logs?

# ? Apr 7, 2015 14:58

PT6A: Jan 5, 2006; Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane

Data Graham posted:

Do you have access to the server's outgoing mail logs?

Not directly, I'm on shared hosting so I don't have access to those but I have submitted a ticket so hopefully this will clear it up.

From all my googling, it doesn't seem like Django ever does this on its own (and it certainly never did it during testing) so I'm 99% sure the e-mails I'm hearing about are being written by my well-meaning colleagues.

# ? Apr 7, 2015 15:37

Gounads: Mar 13, 2013; Where am I?
How did I get here?

PT6A posted:

As far as I can tell, correct me if I'm wrong, Django does not, on its own, send out any form of unsolicited email to users, but I just want to be sure since now I'm hearing about this from my clients and their users, all without any details (since that would just make my life TOO easy).

Correct.

But are you using some extra registration app? It might.

# ? Apr 7, 2015 15:39

PT6A: Jan 5, 2006; Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane

Gounads posted:

Correct.

But are you using some extra registration app? It might.

I'm using allauth for Facebook login, but that's it. I don't think it's sending e-mails either, even though I know it could be configured to do so.

More to the point, I checked the database and the guy who complained is not in, either by e-mail address or first name, so I'm 99% sure that it's some kind of spoofed e-mail that he's been receiving.

EDIT: And now it seems like it may have been sent by an employee after all. Begin the witch hunt!

PT6A fucked around with this message at 17:08 on Apr 7, 2015

# ? Apr 7, 2015 16:05

Hed: Mar 31, 2004; Fun Shoe

I have a project where I'm ingesting a large amount of data, and for this project it makes sense to map each dataset into its own database.

In order to automate the "awareness" of a new database a bit better, I was going to move the DATABASES setting in the production settings.py out to JSON, then when I label a new dataset, fill in the db alias, write out the json, then kick the supervisord to restart the WSGI processes. How bad of an idea is this?

# ? Apr 8, 2015 23:50

2nd Rate Poster: Mar 25, 2004; i started a joke

Hed posted:

I have a project where I'm ingesting a large amount of data, and for this project it makes sense to map each dataset into its own database.

In order to automate the "awareness" of a new database a bit better, I was going to move the DATABASES setting in the production settings.py out to JSON, then when I label a new dataset, fill in the db alias, write out the json, then kick the supervisord to restart the WSGI processes. How bad of an idea is this?

This will do what you want, I think you can make it a bit more seamless though.

I'm guessing at your use cases, but I think I'd do something like this:

- Make a model for your database servers this table should reside in whatever is your 'default' db.
- For queries requiring outside databases, hit your settings.DATABASES first looking for your desired entry returning a using() queryset if your entry was found.
- If no entry was found, I'd hit the DatabaseServer model defined above, and extend settings.DATABASES as needed, then return your proper using() queryset.

That'll give you some hooks to update your db on the fly, and not take any downtime hits. Storing table defs in your DBs means this should work across multiple servers without having to worry about shipping copies of the same json file around.

If you don't like that approach, the key thing to understand is that settings.DATABASES is a dictionary like anything else, you can extend it anywhere and connections will work. Django will stand up connections to new databases as needed.

# ? Apr 9, 2015 04:47

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

Now that I have a better handle on rest_framework, I'm looking into authentication. I'm confused about how I should handle users, though: should I convert my "Employees" model (containing stuff like first and last name, e-mail address, assigned location, permission levels, etc...) into an instance of AbstractUser, or should I keep that stuff as a model, move name and e-mail out of the model since User handles it, and then (somehow) establish a relationship between it and users? If it's the latter, how do I establish a relationship between an instance of User and the user's Employee record? And is it a bad idea to have permissions stored separate from the User table?

Edit: Oh, this looks like a good place to start: https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#extending-the-existing-user-model

IAmKale fucked around with this message at 00:16 on Apr 14, 2015

# ? Apr 13, 2015 23:56

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

Karthe posted:

Now that I have a better handle on rest_framework, I'm looking into authentication. I'm confused about how I should handle users, though: should I convert my "Employees" model (containing stuff like first and last name, e-mail address, assigned location, permission levels, etc...) into an instance of AbstractUser, or should I keep that stuff as a model, move name and e-mail out of the model since User handles it, and then (somehow) establish a relationship between it and users? If it's the latter, how do I establish a relationship between an instance of User and the user's Employee record? And is it a bad idea to have permissions stored separate from the User table?

The way I did this with my Employee model (not sure if this is most ideal but it seems to have worked well) was to keep it as a separate model and not an instance of AbstractUser.

I let python-social-auth create my User records and I use some Django middleware tack the employee record onto the request

code:

class EmployeeMiddleware:
    def process_request(self, request):
        try:
            if request.user.is_authenticated():
                request.employee = Employee.objects.get(email=request.user.email, is_active=True)
        except ObjectDoesNotExist:
            pass

Then throughout my Django views and DRF views I reference request.employee quite a bit to determine what they are allowed to do. In my app I have users create their own Employee record after they've authenticated successfully, prompting for name, title, manager, etc.

I don't use a foreign key to link the user & employee models, I just rely on an exact text match of the email fields.

# ? Apr 14, 2015 00:17

Hed: Mar 31, 2004; Fun Shoe

2nd Rate Poster posted:

great suggestions for databases

thanks! I'm picking this back up at work this week so I think I'll put in your suggestion. Making it at worst one db lookup (to figure out the DB routing) per request is actually a great bargain, and not having to kick over a production server and cross your fingers that it comes back up is even better.

# ? Apr 14, 2015 02:37

Storgar: Oct 31, 2011

I'm having trouble making connections about Django's class based views. I'm lazy and I can't find an example of a Django edit view class.

I want to make a class based view that contains functions to create (post) and delete model instances. (First of all, is this best practice? What do people normally do for this sort of thing?) How can I view the automatic urls generated by this class if I use as_view()? I am fuzzy on how I actually call the class methods from an html form.

Storgar fucked around with this message at 08:26 on Apr 14, 2015

# ? Apr 14, 2015 08:18

cowboy beepboop: Feb 24, 2001

I've been using https://github.com/django-compressor/django-compressor for my css / js postprocessing needs. It's slow as gently caress in 1.8 and the project looks like it may be on life support. Any recommendations?

# ? Apr 14, 2015 10:25

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

my stepdads beer posted:

I've been using https://github.com/django-compressor/django-compressor for my css / js postprocessing needs. It's slow as gently caress in 1.8 and the project looks like it may be on life support. Any recommendations?

Is there a reason to do this with Django rather than tools like webpack or browserify as part of your build process? I've always minified and concatted using those and just referenced those files in Django.

# ? Apr 14, 2015 12:55

Data Graham: Dec 28, 2009; 📈📊🍪😋

Storgar posted:

I'm having trouble making connections about Django's class based views. I'm lazy and I can't find an example of a Django edit view class.

I want to make a class based view that contains functions to create (post) and delete model instances. (First of all, is this best practice? What do people normally do for this sort of thing?) How can I view the automatic urls generated by this class if I use as_view()? I am fuzzy on how I actually call the class methods from an html form.

Where are you reading that class-based views give you automatically generated URLs? That's the first I'm hearing of such a thing. To my knowledge you have to list all your URLs in urls.py.

But yeah, it's perfectly good practice to do like this:

code:

class MyObject(APIView):

    def get(self, request, format=None):
        ....
        return Response({})

    def post(self, request, format=None):
        ....
        return Response({})

    def delete(self, request, format=None):
        ....
        return Response({})

Then hook up urls.py like this:

code:

url(r'^myobject/$', foo.views.MyObject.as_view()),

And that one URL endpoint will handle all the methods you define functions for. You can fiddle with the URL pattern to handle object IDs and the like.

# ? Apr 14, 2015 14:57

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

Lumpy posted:

Is there a reason to do this with Django rather than tools like webpack or browserify as part of your build process? I've always minified and concatted using those and just referenced those files in Django.

What determines when it loads the minified version vs. the development version?

# ? Apr 14, 2015 18:42

Storgar: Oct 31, 2011

Data Graham posted:

Where are you reading that class-based views give you automatically generated URLs? That's the first I'm hearing of such a thing. To my knowledge you have to list all your URLs in urls.py.

But yeah, it's perfectly good practice to do like this:
code:
class MyObject(APIView):

    def get(self, request, format=None):
        ....
        return Response({})

    def post(self, request, format=None):
        ....
        return Response({})

    def delete(self, request, format=None):
        ....
        return Response({})
Then hook up urls.py like this:
code:
url(r'^myobject/$', foo.views.MyObject.as_view()),
And that one URL endpoint will handle all the methods you define functions for. You can fiddle with the URL pattern to handle object IDs and the like.

By "automatically generated urls" what I meant was what you said in your last paragraph. Sorry, imprecise language. I was aware that you could do this, but what I'm curious about is how do I access these view functions from the view side?

For instance, if I want to delete() using the code you wrote, which url do I access? "myobject/delete"? How can I view the urls that were "automatically generated" by as_view() as I awkwardly put it...?

Also another question, if I named the url above, say

code:

url(r'^myobject/$', foo.views.MyObject.as_view(), name="form-object"),

what do I put in the {% url %} template tag? If I want to delete?

# ? Apr 14, 2015 19:26

Data Graham: Dec 28, 2009; 📈📊🍪😋

Nah, it's all the same URL. The only difference is in the HTTP method you use to make the call.

If it's a bare HTML form, you'll have a <form method="POST"> attribute, and that's where you would put DELETE if it's a delete request. Depending on what method you use, Django will route it to the right method call in the class.

Same if you're using jQuery; you'd use $.post() or $.delete() depending. It all goes to the same endpoint.

# ? Apr 14, 2015 19:42

Storgar: Oct 31, 2011

Oh. I thought only POST and GET were supported. Whoops. Ok, mystery solved. Thanks for your help dudes. :cheers:

# ? Apr 14, 2015 19:47

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

fletcher posted:

What determines when it loads the minified version vs. the development version?

I always load the "built" versions, but give my build tools different parameters based on dev or production (i.e. turning off source maps with webpack) so there's no change to your Django / templates.

# ? Apr 14, 2015 21:41

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

Lumpy posted:

I always load the "built" versions, but give my build tools different parameters based on dev or production (i.e. turning off source maps with webpack) so there's no change to your Django / templates.

Interesting...so it's always the same {% static 'whatever.js' %} tag in your templates?

Do you have to do anything special to handle putting some sort of hash in the filename of the static asset to avoid keeping an old version in the end users cache? I like that django-pipeline handles that without me having to think about it.

# ? Apr 14, 2015 22:06

Storgar: Oct 31, 2011

Hold up a sec. I'm using DELETE in the html form method and it's give me output from my get() function. If I'm using pure django (not django rest framework), is there something I'm doing wrong?

# ? Apr 15, 2015 08:31

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

Storgar posted:

Hold up a sec. I'm using DELETE in the html form method and it's give me output from my get() function. If I'm using pure django (not django rest framework), is there something I'm doing wrong?

HTML form element only supports two values for method, post or get: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form#attr-method

In DRF I use a POST with hidden input _method="delete" I think, not sure about vanilla django

# ? Apr 15, 2015 10:30

Data Graham: Dec 28, 2009; 📈📊🍪😋

Yeah, that's why I was suggesting jQuery. (It's been a long time since I used a normal HTML form; I'd forgotten whether the GET/POST thing was in the spec or a limitation in older browsers.)

But if you're using the full REST method suite, I'd think you'd want to be using AJAX for your interactions.

E: To be clear, if you are limited to using plain HTML forms, you probably aren't going to be able to take full advantage of class-based views. You'll have to implement your DELETE method as a separate class and call it with a myobject/delete URL posting to MyObjectDelete.as_view() or the like.

At that point your view structure will be pretty ugly and hybridized, so you might have to just bite the bullet and abandon class-based views, and do straight method-based views for each of your GET and POST and DELETE requests.

Data Graham fucked around with this message at 12:04 on Apr 15, 2015

# ? Apr 15, 2015 11:53

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

fletcher posted:

Interesting...so it's always the same {% static 'whatever.js' %} tag in your templates?

Do you have to do anything special to handle putting some sort of hash in the filename of the static asset to avoid keeping an old version in the end users cache? I like that django-pipeline handles that without me having to think about it.

Hmm... webpack (and others) can dynamically add a hash to the filename (or path, or whatever you want to tell it to do because you config is javascript) so on the one hand, no, you don't have to do anything special. That said, you now have to communicate that new filename to Django. I imagine CachedStaticFilesStorage could come in handy for that type of thing, but to be quite honest, I don't worry about it, which is probably not the best way of handling it, but it sure is easy!

# ? Apr 15, 2015 15:00

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

How can I access URL parameters from within a class extended from rest_framework's BasePermission? I'm trying to make a web application that supports multiple organizations and I want to create a permission to lock down REST requests to an authenticated user's particular company. However, the request object that gets passed into has_permission() doesn't appear to have anything in it:

Python code:

class IsLocationManagerOrHigher(BasePermission):
    def has_permission(self, request, *args, **kwargs):
        print(str(request.query_params)) # returns <QueryDict: {}>
        return True

It looks like I'm limited to reading the request.user's (and whatever else I've attached to the request) data to make permission decisions.

# ? Apr 15, 2015 18:28

Storgar: Oct 31, 2011

Data Graham posted:

Yeah, that's why I was suggesting jQuery. (It's been a long time since I used a normal HTML form; I'd forgotten whether the GET/POST thing was in the spec or a limitation in older browsers.)

But if you're using the full REST method suite, I'd think you'd want to be using AJAX for your interactions.

E: To be clear, if you are limited to using plain HTML forms, you probably aren't going to be able to take full advantage of class-based views. You'll have to implement your DELETE method as a separate class and call it with a myobject/delete URL posting to MyObjectDelete.as_view() or the like.

At that point your view structure will be pretty ugly and hybridized, so you might have to just bite the bullet and abandon class-based views, and do straight method-based views for each of your GET and POST and DELETE requests.

Ah I see. I was hoping to just make a mostly javascript free website for now. I think I'm going to learn Ember.js or something and then come back and redo everything when I have time. I'm not sure how I feel about progressive enhancement anymore.

# ? Apr 16, 2015 05:24

xpander: Sep 2, 2004

I'm trying to modify the queryset for a model, to do simple unit conversion on some of the fields. They are stored as centi<unit>, rather than <unit>, so I just need to divide by 100 and return that as the value of each field. I haven't quite gotten it right, but I'm wondering if overriding the default queryset is the correct approach here. Has anyone done this before? If so, how exactly would I go about this? I want something akin to using update() and an F function, but I don't actually want to update the database - just what is returned via the queryset.

# ? Apr 20, 2015 04:36

Pumpkin Pirate: Feb 2, 2005; ???????

If you can edit the model class, my first inclination would be to add a property to it like this:

code:

@property
def length_m(self):
    return self.lenth_cm / 100

If that's not an option, as of Django 1.8, you can do this:

code:

from django.db.models import F

qs.annotate(length_m = F('length_cm') / 100)

# ? Apr 20, 2015 18:03

xpander: Sep 2, 2004

Pumpkin Pirate posted:

If you can edit the model class, my first inclination would be to add a property to it like this:
code:
@property
def length_m(self):
    return self.lenth_cm / 100
If that's not an option, as of Django 1.8, you can do this:
code:
from django.db.models import F

qs.annotate(length_m = F('length_cm') / 100)

Thanks for this - I've been working a lot with custom model managers and querysets lately, and just using a property hadn't really occurred to me! Works like a charm.

# ? Apr 21, 2015 04:22

Storgar: Oct 31, 2011

I want to put some sort of "popular blog posts" feature on my site, is there anything to do that? I also want to analyze my web traffic to see if I'm getting any, but I don't know where to start with analytics tools. What kinds of python/django packages, web services, or libraries do people usually use?

# ? Apr 23, 2015 18:17

The March Hare: Oct 15, 2006; _{Je r�ve d'un}
Wayne's World 3; Buglord

I'm thinking of giving react a go on Django, just using DRF to supply it with some JSON. I don't really know much/anything about JS tooling and I can't find anything specific to working with Django other than PyReact, which I am now using w/ pipeline to get my jsx stuff compiled down to js on collectstatic.

For those of you using Django w/ React, what is your preferred setup for this stuff? How do you deal w/ module importing (I know node gives you require(), should I just also be using node?)

# ? Apr 25, 2015 19:47

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

The March Hare posted:

I'm thinking of giving react a go on Django, just using DRF to supply it with some JSON. I don't really know much/anything about JS tooling and I can't find anything specific to working with Django other than PyReact, which I am now using w/ pipeline to get my jsx stuff compiled down to js on collectstatic.

For those of you using Django w/ React, what is your preferred setup for this stuff? How do you deal w/ module importing (I know node gives you require(), should I just also be using node?)

I use webpack, but browserify is also a good option. Unless you are doing isomorphic server side rendering, basically have one of those tools build and output to your static files and you are good to go. I'm sure Thermoplye and Mulco will have more betterer input as well.

# ? Apr 25, 2015 20:10

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

The March Hare posted:

I'm thinking of giving react a go on Django, just using DRF to supply it with some JSON. I don't really know much/anything about JS tooling and I can't find anything specific to working with Django other than PyReact, which I am now using w/ pipeline to get my jsx stuff compiled down to js on collectstatic.

For those of you using Django w/ React, what is your preferred setup for this stuff? How do you deal w/ module importing (I know node gives you require(), should I just also be using node?)

The best way to do Django and React is to have two separate projects. Have a Django project that provides an API with DRF and then a separate front end project that uses React and uses that API.

In the front end project use webpack or browserify like Lumpy says. With those you just require modules that you install with npm, and webpack/browserify packages them up for the browser.

# ? Apr 25, 2015 20:28

The March Hare: Oct 15, 2006; _{Je r�ve d'un}
Wayne's World 3; Buglord

Thermopyle posted:

The best way to do Django and React is to have two separate projects. Have a Django project that provides an API with DRF and then a separate front end project that uses React and uses that API.

In the front end project use webpack or browserify like Lumpy says. With those you just require modules that you install with npm, and webpack/browserify packages them up for the browser.

Awesome, I think I was hung up on thinking I'd want to be using Django to manage the react project, but full separation makes much more sense. Thanks dudes

# ? Apr 25, 2015 20:42

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Yeah, separate entirely. If you want to be like me and run a project where Django is perfect for managing the data, but prefer to render in Jade/React and get the benefits of an isomorphic application, you need to build a separate view server in Node that Django sends JSON to. This doesn't have to be particularly complex on the django side.

code:

import requests # pip install requests
from myproject.to_view_layer import build_context
import json

def view_layer(request, path, payload):
    url = "{0}{1}".format(settings.VIEW_LAYER_URL, path)

    final_payload = build_context(request)
    final_payload.update(payload)
    r = requests.put(
        url,
        data=json.dumps(final_payload),
        headers={ 'content-type': 'application/json' }
    )
    if int(r.status_code) >= 500:
        raise Exception(r.text)
    else:
        return HttpResponse(r.text)

One advantage of this approach is that you can essentially build all the front end components and templates in a single pass, without having to adapt them to Django's template system or workflow.

My colleague and I ended up at this workflow fairly gradually, but it has allowed us to deliver a pretty non-trivial project with a minimum of backtracking, so I feel like we're doing something right even if our approach will still require fine tuning.

It should hopefully go without saying that you need to figure out a way to convert your data into JSON if you take this approach. Isomorphic also adds some extra challenges, such as image resizing for picturefill implementations, and how to get the right data to the client for rendering React components.

Another thing, if you're not aiming for an isomorphic application, just a simple "React application talks to JSON service" application, it can help to build a dummy API in Node while you're developing. The advantage is you won't be context switching all the time, and your Dummy API can be poo poo anyway because you don't need to rely on security/validation etc so much. This really depends on the project though.

...if anyone is interested in how this view layer thing went once we ship (and hopefully not crash and burn), I might write up a bit more about how it got put together.

# ? Apr 26, 2015 04:19

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Maluco Marinero posted:

...if anyone is interested in how this view layer thing went once we ship (and hopefully not crash and burn), I might write up a bit more about how it got put together.

/me raises hand

# ? Apr 26, 2015 06:12

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

I've created a @list_route() to make it easy for end users to query confirmed records, but I'm not sure which of the following is the preferred way of filtering:

Method 1 (I've removed a bunch of code from the View):

Python code:

class ShiftViewSetForEmployees(viewsets.ModelViewSet):
    def get_queryset(self):
        return Shift.objects.filter(employee=self.request.employee)

    @list_route()
    def confirmed(self, request, pk=None):
        conf_shifts = self.get_queryset().filter(confirmed=True)

Method 2:

Python code:

class ShiftViewSetForEmployees(viewsets.ModelViewSet):
    def get_queryset(self):
        return Shift.objects.filter(employee=self.request.employee)

    @list_route()
    def confirmed(self, request, pk=None):
        conf_shifts = Shift.objects.filter(employee=request.employee, confirmed=True)

My main concern is that, in Method 1, two database queries are made vs what I'm guessing is a singe query in Method 2. Is this not how DRF works when it comes to retrieving objects?

# ? Apr 28, 2015 18:59

Eleeleth: Jun 21, 2009; Damn, that is one suave eel.

You're fine with either method. Both of those will only result in one database hit, due to how django handles querysets: https://docs.djangoproject.com/en/1.8/ref/models/querysets/#when-querysets-are-evaluated

I'd prefer method 1, myself, since you're repeating yourself otherwise.

# ? Apr 28, 2015 19:41

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

Eleeleth posted:

You're fine with either method. Both of those will only result in one database hit, due to how django handles querysets: https://docs.djangoproject.com/en/1.8/ref/models/querysets/#when-querysets-are-evaluated

I'd prefer method 1, myself, since you're repeating yourself otherwise.

Yeah, I prefer Method 1 so I'm glad to see that it's a sane way of filtering further. Thanks for linking me to that Django doc, that makes it quite clear why it's an Alright Thing To Do.

I have another question, this time about clearing up some redundant code that's popping up in many of my views. Right now I have this scattered about some of my view's get_queryset():

Python code:

if self.request.employee.is_admin:
    company = get_employee_company(self.request.employee)
    return Station.objects.filter(location__company__id=company.id)
elif self.request.employee.is_manager:
    return Station.objects.filter(
        location__id=self.request.employee.location.id)

The main difference between all of this similar code is the parameter that's passed to the model's filter() method. I know I want to write a single method I can call instead, something like this pseudocode:

Python code:

def filter_queryset_on_role(self, employee, model, admin_filter, manager_filter, ...):
  if employee.is_admin:
      company = get_employee_company(employee)
      return model.objects.filter(admin_filter)
  elif employee.is_manager:
      return model.objects.filter(manager_filter)

Unfortunately I don't know how to pass those filter() parameters as parameters to my custom function. Ideally I could do something like this...

Python code:

filter_queryset_on_role(
	self.request.employee,
	Station,
	location__company__id=company.id,
	location__id=self.request.employee.location.id)

...and filter_queryset_on_role() would apply the filter as model.objects.filter(location__company__id=company.id) or whatever else gets passed. The filter parameters will vary between models, obviously, so I can't rely on any fixed values I can pull from kwargs. As a result I'm stumped. Any clues as to how I might accomplish this?

# ? Apr 28, 2015 20:02

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 08:00

epswing: Nov 4, 2003; Soiled Meat

I seem to be getting "Forbidden 403, CSRF cookie not set" on IE, FIreFox, and Chrome, when running the local dev server. I'm getting the error when submitting the standard django admin site login form. I don't think it's likely that all of a sudden none of the browsers on my machine are accepting cookies. What else could cause this? I can see the csrfmiddlewaretoken hidden input in the html source.

Django 1.7.7

Edit: Got it. I had set

code:

SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True

in settings.py, as the site in production forces https.

Of course, the development server is just http :3:

epswing fucked around with this message at 18:52 on May 28, 2015

# ? May 28, 2015 17:32

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass

«‹›122 »