For some reason, my /admin page has made the models I defined un-editable. This is on my deployed server using apache and postgres. I'm logged in as a superuser and the is showing the links like this:
If I look at the same code locally in the development server connected to postgres, it looks like this:
Any idea what could be causing this?
** Update **
So it's not always blocked. I logged in today and I had access for a few actions (I cleaned some bogus email requests from my DB) but then after deleting some rows it got back to the read-only state.
Still no idea what's causing it.
home.models.py:
from django.db import models
from django import forms
from django.utils import timezone
class EmailRequest(models.Model):
email = models.EmailField()
created_date = models.DateTimeField(default=timezone.now())
class EmailRequestForm(forms.Form):
email = forms.EmailField()
home.admin.py:
from django.contrib import admin
from home.models import EmailRequest
class EmailRequestAdmin(admin.ModelAdmin):
list_display = ('email', 'created_date')
admin.site.register(EmailRequest, EmailRequestAdmin)
I don't have a direct answer to your problem, but I do have a few personal insights. First of all, using the Bitnami Django stack is probably a problem. I have used it a couple of times, and I never will again. The setup is definitely NOT ideal, and there is way too little documentation available for it to make your life any easier (wait, wasn't that the whole point of using a Bitnami stack?).
I would start looking through your logs (apache error log and postgres error logs specifically), I bet there is something in there that will point you in the correct direction.
I am sure you are running your development server from your local machine which is setup completely differently from the Bitnami stack. The better solution would be to install everything yourself on a barebones Ubuntu server. Then you will have much more familiarity with the setup.
THE BEST THING you can do, is go learn to use Vagrant. This will help you to maintain a local virtual machine instance, which is identical to your EC2 box. You will log into it using ssh just like the EC2 box, and you will be using it externally, just like the EC2 box. The closer you can get your development environment to your production environment, the easier debugging problems like this will be.
Hope that didn't make your life more difficult (seriously, if you get Vagrant running, your life will become MUCH easier)
See the following solution:
No access to models in admin panel with DEBUG=False
quote:
OK, I've found reason of my problems. It was caused by registering my
models in admin panel from files with models definitions. When I moved
all my registrations to one external file admin.py, then everything
works correctly.
Related
Django 1.11
If I click Groups in Django admin site, I can see a list of groups. Namely, the address is http://localhost:8000/admin/auth/group/
I monitor the CPU usage in terminal. Python is consuming 4-5 % now.
I have organized 4 groups. So, if I click any group, the server just calculating something for several minutes. The address now is like http://localhost:8000/admin/auth/group/6/change/
Maybe about 5 minutes the server is calculating something. And Python is now consuming 100 % of CPU resources.
Well, Django admin is analyzing something.
I have about 23-25 models. Well, this is not a very big number of models.
Each model is 3 standard permissions (add, change, delete). And I created one permission myself in the Meta class of a model.
So, as soon as "Change group" page is in front of me with available permissions and chosen permissions, CPU consumption by Python is again 4-5 %.
Could you comment on this? Is it curable?
Came across this issue when using django debug toolbar with the built in django admin app. The change/update page was incredibly slow locally (sometimes it would not load at all) but if I set DEBUG=False (thus turning the debug toolbar off) it worked as expected. In my particular case, I didn't need the debug toolbar for the admin app so I disabled it for only those admin URLS like so:
# settings.py
DEBUG = True
def show_toolbar(request):
# disable debug toolbar for built in admin app urls only
if request.path.startswith('/admin'):
return False
else:
return True
DEBUG_TOOLBAR_CONFIG = {
'SHOW_TOOLBAR_CALLBACK': show_toolbar,
}
We're using the same setup as Max Malysh:
Django 1.11
A custom User model based on django.contrib.auth.models.AbstractUser
The custom user model set in the settings via AUTH_USER_MODEL variable
We've got the same issues and I think I found the issue, or at least the module which is causing the delays. It has nothing to do with Django and/or the DEBUG mode itself, because I think the issue is within the debug_toolbar.
If you deactivate the debug_toolbar application and debug_toolbar.middleware.DebugToolbarMiddleware middleware, it works like a charm.
I didn't had the time to reverse-engineer it, but I'll have a look at it when I find the time. In the meantime and as a workaround, deactivate the debug toolbar if you don't need it.
Sorry, it's not a final solution yet, but I thought I'll share my findings in case they can help somebody.
Cheers
Domi
EDIT/UPDATE: It has something to do with the Template panel of the Debug Toolbar. If you deactivate it, you'll have a much faster response time!
I've encountered the same problem when adding a new group with Debug=True in settings.py.
The same code works fine with Debug=False.
Some background information:
We use Django 1.11
We use custom user model inheriting from AbstractBaseUser
There are ~30 models registered on the admin site
Django debug toolbar output:
I was experiencing this same problem, but probably for a different reason than the OP was.
If you have a large number of Users, look at your admin.py and make sure that you are not displaying Users inline on the Group admin page. That can cause very slow loading of the Group admin page if the Group has a large number of users in it.
In my work we want to run a server with multiple databases. The databases switching should occur when you acces a url like http://myapp.webpage.com or http://other.webpage.com. We want to run only one server instance and at the moment of the HTTP request switch the database and return the corresponding response.
We've been looking for a mantainable and 'Django-friendly' solution. In our investigation we have found possible ways to do this, but we have not enough information about.
Option 1: Django middleware
The django middleware runs each time the server receive a HTTP request.
Making a database switch here could be the best option but using django database routers as far as I know only allow to change the database for a model or group or models.
Another option is to set a django model manager instance in the middleware and force all models to re-assign the objects attribute from an added attribute in the custom middleware.
My last option is to create a new attribute in the request object received by the middleware that return the database alias from settings.py and in each model query use the using method.
Option 2: Class-based View Mixin
Create a mixin that use the past three options, but I the mixin must be set in ALL the Class-based views. If a programmer forget to set the mixin and it comes to a production server, the data could be (or stop being) in the right database, and I don't wanna take the risk.
Option 3: Changing the database settings in runtime
This option works but Is not recommended and is too risky.
UPDATE:
How this works?
middlewares.py
import django.conf as conf
import os.path
class SelectDB(object):
def process_request(self, request):
print request.META['HTTP_REFERER']
file_database = open("booklog/database.txt", "r")
database = file_database.read(10)
file_database.close()
if database != 'default':
conf.settings.DATABASES['default']['NAME'] = database
Any information that help us to solve will be greatly appreciated.
Answer (it worked for me)
The question was already answered here, in stackoverflow. I'd love this functionality were in django. It was a bit hard to find the way to make this possible.
I think that is important to comment the great work that Wilduck made with the django plugin django-dynamic-db-router, it's a great plugin that makes possible this operation in (a bit) different way.
Thanks a lot to #JL Peyret and #ire_and_curses.
And as an answer to #ire_and_curses. At least in this moment, in the project I'm working it's what we need. In previous projects we needed a similar behavior and made one server per instance was terrible to mantain and update each server, even automating the process.
I'm getting this weird AttributeError on the app I'm currently working on. I'm developing using the development web server i.e. "runserver" command of django toolsets. Then I decided to test the application on apache+mod-wsgi and I persistently get this error though it works fine sometimes. So I think there must be something wrong with that piece of code,
so I decided to comment it out and see what happens. And YES, it still give me the same error (See 2nd picture). <-- NOT RELEVANT NOW. The AttributeError I'm getting on custom User model, even if it actually contains the classmethod get_by_type_and_id() is what I'm interested on.
Have you even seen like this one before? What do you think is causing this? I've followed the tutorial here to deploy it. Note though that User is not the built-in django User model. I think it's a "customized,stripped-down" implementation based from the django's Auth module.
Note that I have not gotten this error on my development using django's own development server. This only happens when I deployed the app on Apache+mod_wsgi.
More Info:
Django version == 1.2.5
Thanks! I'd really appreciate any kind of help.
First Picture:
2nd Picture:
Few things to notice:
Are you sure that you have get_by_type_and_id method for the User?
You set pasword instead of password (typo)
I think you have to indent line 60 in your second screenshot
After hours of diving into the code, I had a eureka moment. So I thought, maybe at some point django.contrib.auth.models.User model is being put into action by some django module used in the application. Because like I mentioned, this app's User model is customized and the application is not using django.contrib.auth.* at least directly. This was my suspicion because this kind of error is not specific to that particular attribute. Sometimes it gets through that point, but then another AttributeError would occur on some other view referring to other User model attributes. Then at one point I noticed that the attributes of User in the error messages was that of django.contrib.auth.models.User.
So I decided to "remove" django.contrib.auth.models on my python path, and there it showed, an error occurred in one of the modules I'm using specifically django.contrib.messages. I removed it, and I'm not seeing the AttributeError again. It turned out that django's Message model has a foreign_key to django.contrib.auth.models.User.
But then, I lost the flexibility of django message framework, especially when I'm using it on view with a HttpResponseRedirect i.e. no way to put useful messages in a template's context. or maybe there is? :)
UPDATE 2 (Pretty Sure Now):
Yes, I'm pretty sure now that django.contrib.messages is the one causing the error. I tried reproducing the error on another application which uses the customized User model i.e. not django.contrib.auth.models.User. I enabled django.contrib.messages module and produced basically the same error. I would like to know why is this happening on Apache+mod_wsgi, but not on django's own development server.
I have a django website that I am hosting on twisted via the django WSGIHandler as described here - http://www.clemesha.org/blog/Django-on-Twisted-using-latest-twisted-web-wsgi
All seems OK up to the point where I want to add an extra "site" configuration to my django site using the django Sites framework. Doing so, I add an extra settings.py file for the new site and that seems to work.
What I then want to do is use the twisted NameVirtualHost class to be able to direct one domain (say site1.example.com) to the first settings file, then use another domain (say site2.example.com) to use the second settings file. This works with Apache & mod_wsgi.
The problem I face is that the twisted code can only access one django environment at a time. If I call setup_environ with the first settings file and setup a host for the first domain, a subsequent call to setup_environ will replace the settings file in use so therefore only one set of settings can be used at one time.
Any ideas how to proceed?
Gave up on this in the end. Looks like you cannot easily access 2 Django environments within the same twisted instance. I think it would require multiple instances of twisted with a reverse proxy or some sort of multiprocess hacking - either way its not worth the effort for me so I'm going to try something else...
I am using django 1.2 to create a multi site shop. I need multiple admin logins for each shop instance, e.g.
site.com/au/admin
site.com/uk/admin
and so on.
I have a middleware class and a dbrouter that handles database connections based on the URL. This works fine.
I am trying to add some customisation per admin system based on what is available for that particular shop. So:
in admin.py :
if country == 'au':
admin.site.register(Orders)
admin.site.register(Payment)
if country == 'uk':
admin.site.register(Store_locator)
etc.
Hers's the problem: If I log into the AU version of the site the admin system displays the correct elements for AU. If I then log into UK, it still shows the AU version of the admin system, so the above code seems to only get used on the first load. if I kill the django server and restart it, then go into the different shop admin page, it will have reconfigured for that shop.
How I can get it to pick up a change in country each time the admin system loads? Why is this problem happening in the first place?
Any help would be greatly appreciated.
Thanks,
imanc
I'd bet that Django doesn't read the admin config on each request, but on each time the server is restarted - that's why it 'sticks' to whichever you accessed first.
Why not do something with Django.contrib.auth's permissions to limit what a particular admin user can see in the admin, and register all the models in admin.py as standard?