I'm currently working on a Django project which will be available to use by several companies and their particular data about their clients.
My question is if it is possible to adjust Django admin panel somehow, so that any user could log in (in this case the particular company worker) and have an access to admin tools, but only for the data related to his company (in this case the company clients)?
Example:
Worker of company X logs in and checks status of clients of his company, changes some data etc. At the same time worker of company Y logs in and does the same work with the clients related only to company Y. Both users see only clients related to their own company - they don't have access to other company's data.
I've found something like this, but I'm not sure if it's appropriate to my situation :P
I think the thread you linked is pretty much what you want to do :)
I had to do something similar (role based filtering of displayed objects) and was also overriding the get_queryset method in order to achieve what I had to.
I think the accepted answer in that thread gives a pretty good overview of how to approach it.
Related
Problem Statement
I'm working on building out a single-page Django web app and am trying to implement the following functionality:
- All viewers of the page are associated with a state. There are buttons on the page which enable viewers to change their state.
- The application stores a list of all current viewers of the page, and their associated states. Whenever a user changes their state, this stored list of viewers updates with this new information.
- The application should display how many people are online (viewing the page) at a given time.
Blockers
I'm unsure of how to collect a list of all current viewers of a page in Django, nor how to collect how many users are currently viewing the page.
Ideally, my application would not require a login to use: therefore, I'd rather either associate viewer state with a user object that doesn't require sign-in, or not associate viewer state with a user object (I'm still new to user objects though, so forgive me if this point doesn't make complete sense).
What I'm Looking For
A discussion of higher-level strategies which I can use to implement this functionality, or other places to look to gain insight in tackling my problem. I'm pretty new to Django, so I'd appreciate it if answers also direct me to locations in my Django project which are of relevance (e.g. "Consider doing X in views.py, then..."). Alternatively, if there are GitHub projects you know of with similar functionality, if you could direct me to them to investigate further, that would also be appreciated.
I'd be happy to offer further clarification as required. Thanks in advance!
I'd like to create a tooltip bubbles for my site for new users - many other sites do this (most google apps). I'd like to show them for all accounts created within the last week, unless the user specifically 'dismisses' the tip.
I thought about doing this with cookies - ie. set a "-dismissed=True" value that I could check as well as the account creation date and determine whether to show the tips.
However - this doesn't work across browsers, since cookies aren't shared between browsers. So if a user logs into chrome, dismisses the tip then logs in in FF the tip will reappear.
Does anyone know if there is common way to do this sort of thing? Or at least a better way than what i've described?
I'm using browser length sessions so I can't store it in the session.
You could have a user preferences model, with a one-to-one relationship to the main user model, which stores preferences like this. Create an instance when the user entry itself is created, and default the 'show tips' field to True.
You could also use the new custom user model functionality in 1.5 to store this in the user model itself, but that seems like overkill here.
I'm building a Django-based review website where public users create all of the content on the site. Users create reviews for given items and they also create the items themselves that will be reviewed (providing a description and brief summary of the item, along with a few tags).
My question is this: Should I be using Django's admin features for this website (as in, exposing admin controls to the public users)? Or should I just stick with normal forms? I'm not too familiar with the admin-aspect of Django, and so far I've just been using forms for the website, but I've seen a lot of people talking about Django's admin features, and I'm starting to wonder if I should be using them.
Thanks for any feedback!
Maybe. If the admin functionality covers most of what you want to offer, there's no reason why you shouldn't use it as a starting point.
django.contrib.admin is an application like any other, and provides basically a CRUD interface to your models. Access can be controlled via groups/permissions, just like you would for an application you write yourself. You can give full access to a model with a one-liner, but obviously will have to configure properly when opening up to others.
See also my question
Django AdminSite/ModelAdmin for end users?
and similar questions Exposing django admin to users. Harmful? and How to make Django admin site accessed by non-staff user?
Regarding arguments about the "intended use" of the admin, please note Django's security update at the end of last year: http://www.djangoproject.com/weblog/2010/dec/22/security/ regarding querystring parameters in object lists. Such an update (quote: "an attacker with access to the admin [...]") is a clear indication that the admin's implementation of the permission system is being constantly scrutinized.
No. The django admin is not intended for any end-user.
The django admin feature is intended to assist the website developer, and that is all. Even usage by site administrators is contra-indicated, although in practice most small sites get away with it since they're only talking a few people who can call on the developer personally if they get into trouble.
For your purposes, the review items and the workflow in creating the items is a critical part of your application feature set. The admin will give you ideas, but it would be a mistake to attempt to build your application upon it.
I wouldn't expose the admin interface to regular users. You can use the authentication and user-management side (for your purposes), but it's usually best practice to give users a separate way to manage their objects. You also don't run as much of a risk of granting the wrong privileges to users (or allowing them to grant their own).
Have a read though the docs if you want a better overview about what it can do.
I have recently being trying to create a project which has several levels of user involved.
(Just an example of an abbreviated and rough schema)
ME (Super User)
Client(s)
Customer(s)
Survey Collections
SurveyUser(s)
Invitee(s)
Surveys
Invitee(s) (invitee is a child of both survey and user)
Questions
Etc
I would ideally have:
www.example.com/client/ go to a client interface which you had to be a client to access
www.example.com/customer/ go to a customer interface which you had to be a customer to access
I have already established that using a customised Django admin interface for all of them is probably not going to be possible (or is it?). I am therefore leaning towards manually creating 'admin' interfaces for each level of user, allowing them to manage their respective roles. What is the best way of having different user types and separate interfaces for each one?
I like the way of inheriting users outlined at:
http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-with-inheritance/
But am unsure how I would set up different 'admin' areas for different users.
As a side issue that is related, I am also unsure of how to access the custom properties alongside standard user properties and how to edit/save them in the ACTUAL admin interface that I will use.
I would need to authenticate 'Client' users against a client database to check they are clients but somehow also authenticate against the user database which manages authentication, username, password etc.
I am switching from PHP to Python/Django so any advice greatly appreciated to help me along.
Thanks!
The closest I got to this was based on another stackoverflow article here: How to have 2 different admin sites in a Django project?
I ended up creating two entirely separate instances of django.contrib.admin.sites.AdminSite which seemed to work in the end, albeit not ideal.
Does anyone know a good link to documentation about Pinax signup and "Accounts". I'm trying to work out how to implement our sign-up process in Django / Pinax and am trying to navigate my way between Django's User and Profile classes and the Account class in Pinax..
The main issue for us is we have a sign-up form with several extra questions that must be answered at the point of requesting an account. Membership then needs to be accepted by an admin before the account is enabled. At which point, the answers to these extra questions will be stored in the user's profile.
I'm torn between two rival approaches.
1) Create the User and Profile object at the time of the request. But flag them as "pending" in some way, until approval.
2) Create some kind of alternative model class to temporarily store these values until approval. At which point I create the User and Profile objects and copy the information into them.
I'm trying to infer from the Pinax signup code which of these approaches is most "with the grain" of Pinax, but it's not clear.
So, experienced Django/Pinax developers. Which of these is the more "pinactic" way to go about things?
There are two variants of (1): (a) you just rely on the active flag on User; (b) you denomormalize and have a similar flag on your profile to avoid a join.
The main challenge with approach (1) is that you then have to make sure that any time you are retrieving profiles, you filter them based on this flag. Of course, that's not an issue for something like Account which only the logged in user sees. But for Profile that could be a bit of a pain.
(2) doesn't have that problem. You could avoid some redundancy in that case by using an abstract base model shared by both your temporary profile and main profile models.
Bottom line is I don't think there's an obvious "pinactic" way to do it, although personally I'm leaning towards (2).
Most of the documentation is either here: http://pinaxproject.com/docs/dev/ or here: http://code.pinaxproject.com/wiki/ or else in the code base.
It's seems recently they've been working on the code more and documentation less since they're working up to a stable release so those docs aren't very up-to-date.
That said, Pinax already has a mechanism that delays activating accounts until they've validated their e-mail address (approach #1). The related settings are: ACCOUNT_REQUIRED_EMAIL and ACCOUNT_EMAIL_VERIFICATION so a search on the code base should revealed how/where they're used (which you may be able to extend to use for your extra questions).
I believe they accomplish this by giving each User an "Active" flag (Check out the User object in Admin) which isn't set to True until they verify their e-mail address. I vaguely remember setting this manually one time and still being unable to login with that particular User so you'll want to test this out.