I am working on upgrading a Django website from Django 1.8 to Django 2.2 and have come across a problem when trying to delete an object from the Django admin changelist view. When I try to delete an object, I am shown a screen with the words "Deleting the selected Records would result in deleting related objects, but your account doesn't have permission to delete the following types of objects". The problem is, I am a superuser and should have permission to delete any object I want, or so I thought.
I have read a decent amount of documentation on Django upgrades and permissions of superusers, however I haven't stumbled across anything that helps me (I could be missing something though). I have tried creating a new superuser just in case, still the same message occurs though. Anyway, Does anyone have any idea why this could be happening?
Note: I can't show any code because I am working for a company and I signed an NDA. Just some help pointing me in the right direction would be appreciated.
For anyone else who stumbles across this problem, dirkgroten was right and it turns out the has_delete_permission was overridden! Thanks for your help dirkgroten!
OPENEDX If You are facing This issue then do this thing from the backend.
Cannot delete user
Deleting the selected user would result in deleting related objects, but your account doesn't have permission to delete the following types of objects:
course enrollment
Open Mysql In EDX server like AWS
then
get user id based on username
then student_courseenrollment delete from this user
Example
select id from auth_user where username = 'exampleusername'
delete from student_courseenrollment where user_id = get user_id from 1 query set;
like delete from student_courseenrollment where user_id = 123;
Related
I am new to Django and discovered something I do not quite understand: I extended the default user class of django auth with a custom field to look like this:
class User(AbstractUser):
business_entity = models.ForeignKey('BusinessEntity', on_delete=models.PROTECT)
In the settings file, I also added the needed AUTH_USER_MODEL = 'core.User' since my new user model is located in the core app. Works fine so far.
After applying all migrations (even after wiping the database and reapplying), I, however, am left with a few additional tables that I did not want to create and that seem not to be used by Django's auth app:
Tables created after migration
As you can see there are from the auth app: auth_group, auth_group_permissions and auth_permissions as well as from core app: core_user_groups, core_user_user_permissions.
I searched quite a while - maybe with the wrong keywords? - but I am not able to figure out if I need all those tables and - especially - what the additional core tables are used for. Can you shed some light on this?
Thank you very much!
I am quite sure those are the tables that django uses to store permissions and you shouldn't delete them. For instance, when you make a superuser (an admin), django knows that only he/she can access the /admin page. This knowledge comes from permissions stored in those tables.
If you are not using those tables chances are they only occupy a minimum amount of space (according to the link below, only 4 permissions are added by default) and you shouldn't worry about them. That said, knowing how to manage permissions well can help a lot depending on your project.
More info about permissions can be seen here.
I have a problem with my Django project. I need to delete 1 or more users from my database but I can't do it because it returns this error:
__str__ returned non-string (type tuple)
I tried deleting it from my views but it didn't work. Than I went and used admin panel to try to delete it but the same problem happened.
If someone could give some advice or suggestion that would be great.
Thank you.
I found out what was the problem. I was returning tuple in my models __str__ function instead of a string which worked while users existed but it for some reason didn't when I tried to delete or as I later found out create a new user.
I have a model with a uniqueblogname element that is set to Unique=True. In my views, I do something like:
try:
MyModel.objects.get(uniqueblogname=userinput) #i ask the user to input
#a name of a blog they want to own on the site (all blogs must have a unique name)
#if taken then prints some error messages that the blog name is taken.....
except MyModel.DoesNotExist:
MyModel.objects.create(uniqueblogname=userinput) #if no blog has that name then
#the blog object is created
I recently updated my db by doing dumpdata and loaddata to a brand new blank db and migrating new model changes to this db (I wanted to keep the old db how it was and archive it). Everything went smoothly. New migrations were made without errors. However, now whenever I execute the above check, if I search for any old blogname then I get this error:
1062, "Duplicate entry (the user's input here) for key 'uniqueblogname'"
However, if I search for a completely new blogname and the object gets created then I search for it again using this check, everything works fine. It seems as if the code for trying to retrieve the old MyModel objects does not get properly executed and django tries to create a new MyModel only to realize that it would be a duplicate and so throw this error.
The most confusing part about this error is like I said: If I create a completely new blogname and enter it, and the object is created freshly within this new db, this check condition works every time perfectly (so I don't suspect it is a logic issue in my code). However, I can't seem to check my older stuff that I used loaddata to populate.
Any ideas? Very appreciative of any suggestions. Thanks.
It's hard to comment on your specific case without knowing more. I'd start by looking at the database itself and seeing if there's anything different about your old rows as opposed to the newly created rows.
I do want to point out that your current code has a race condition, since another process could insert a row with the same name in between the get() and the create(). I suggest using get_or_create() instead.
This method is atomic assuming correct usage, correct database configuration, and correct behavior of the underlying database.
I want to let users to add new field.
How to add new field in database from user or admin interface (except to use South)?
The Django docs show how to run raw sql. So if you connect to the db as a user with the correct privileges you can run ALTER TABLE statements.
HOWEVER you REALLY REALLY have to sanitise your inputs properly otherwise you may as well just put the root password on the front page of your site.
And all that said... there's almost certainly a better approach to solving your problem. You should describe in more detail what you're trying to do.
I'm working on a project,
this project must have many users, each user can create for examples many support tickets and he could see them and edit them, but he is not allowed to access any other ticket, which not belong to him
so for example :
def edit_ticket():
record = db.e_ticket(request.args(0),active=True) or redirect(URL('error'))
form=crud.update(db.e_ticket,record,next='view_ticket/[id]')
return dict(form=form)
in this way with (request.args(0)) the user can edit every ticket in the system just to change the id to any other id and it will work
edit_ticket/[id]
so i changed the request.args(0) with auth.user_id, it was a great solution as i thought! but when we've many users so only the 1st and 2ed user could edit this thier tickets the next users cannot do that and receive an error when they do this "edit_Ticket/[id]"
Error the document doesn't exist
what should i do to prevent users from bypassing their privilege
Regards
it shouldn't be:
db.e_ticket(request.args(0),user_id==auth.user_id,active==True)
but
db.e_ticket(request.args(0),user_id=auth.user_id,active=True) -
because here we're passing function arguments and not query conditions
web2py has buildin user access control. please reference the web2py book:
users should login to edit their ticket, so you can use #auth.requires_login() to decorate edit_ticket(). In edit_ticket() you can check whether the user_id has the ticket_id first.
Maybe look into using authorization and CRUD (and generally how to set permissions on particular database records).
Note, you can't replace request.args(0) with auth.user_id. request.args(0) is referring to the id of the e_ticket record, not the user id. If the e_ticket table includes a field referencing the user id (e.g., e_ticket.user_id), then you could add user_id=auth.user_id as a condition.
next='view_ticket/[id]'
You should use the URL() function to create URLs -- URL(f='view_ticket',args=[id]). Also, what is [id] supposed to be -- I don't see any reference to id in the code?