Re: filtered admin change-list
thank you, it worked. I wrote queryset, has_change_permission and save_model in my ModelAdmin. As i see it, django-guardian intended for low level permissions in the web application itself, not the admin-interface. By the way, is it safe and secure to allow any user (which is not superuser and is not trusted) to log in the admin interface (by marking every new user as 'is_staff'=True) when restricting his permissions to change only the objects he owns? On Mar 23, 11:33 am, Marc Aymerich wrote: > On Sun, Mar 18, 2012 at 12:07 AM, omerd wrote: > > Hi, > > > I want to be able to show parts of the change list, by the user that > > view it. > > The case is that every super-user can create instances of a certain > > model. I wan't that in the change-list page of that model in the admin > > site, every user will see only the instances that he'd created. Of > > course, this user doesn't have permissions to view or edit instances > > of other users. > > > What is the best approach to accomplish this? > > take a look at this project:https://github.com/lukaszb/django-guardian > > or search in google by: django admin row level permission > -- > Marc -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: filtered admin change-list
thank you. I will try it On 19 מרץ, 19:26, Rajeesh Nair wrote: > Add a field on your model to identify the user who created each instance & > then extend your model_admin's queryset method to filter queryset by the > user. > > > > > > > > On Sunday, March 18, 2012 4:37:43 AM UTC+5:30, omerd wrote: > > > every user will see only the instances that he'd created. Of > > course, this user doesn't have permissions to view or edit instances > > of other users. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
filtered admin change-list
Hi, I want to be able to show parts of the change list, by the user that view it. The case is that every super-user can create instances of a certain model. I wan't that in the change-list page of that model in the admin site, every user will see only the instances that he'd created. Of course, this user doesn't have permissions to view or edit instances of other users. What is the best approach to accomplish this? -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django models design question
Thank you very much! I choose the first option for now. If I have any problems, I will write them here On Oct 17, 2:51 pm, Stuart wrote: > Hello Omer -- > > I believe you have two options. You could use the AttributeValue > approach I described earlier. You could add features to take care of > 'data types' and the like. The work may be quite tedious, but it has > the advantage of not being clever. In other words, you would do the > work to implement each feature as you like, with no magic involved. > > The other approach is to extend django/python itself. Basically the > approach here is what has been called dynamic models. You can google > for it, but your best bet is probably this blog post and the pages it > references.http://martyalchin.com/2007/aug/14/dynamic-models-in-real-world/ > However, note that the article is over four years old. You would no > doubt have to update this approach for django 1.3. This approach would > require knowledge of django/python extension points and likely some > internals. It's probably the "better" approach assuming you are up for > it. You would have to decide when to construct these dynamic models, > among many other decisions. > > I'm on holiday for the next couple days, but I will check back with > the list to see how you're getting on when I return. > > Good luck! > > --Stuart -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django models design question
I should also mention that one AttributeValue table for all the registrations isn't good for my purpose, because it says that the Value column must have a specific type field. I want that every detail (Atrribute) will have the option to be from any field type (CharField,DateTimeField, etc). On Oct 15, 9:37 pm, omerd wrote: > Thank you for the response. > > As stuart wrote, i should give more details about the website. > Currently let's suppose I have 2 interesting tables (I'm not sure that > the relationship between these 2 tables is well designed): > > 1. Details, that contains all the possible information that should be > provided to register for something. > For example: first name, last name, phone number, address etc. > > I should mention again that every registration needs other set of > details > > 2. Registration, that have the following columns: > admin (the admin of the registration), registration_name,id , foreign > key to Details(many to many). > > actually, I chose the first model that sturat described. I wan't that > some users that have the appropriate privileges (super-user) will be > able to define new registration for something. For example, let's > suppose that a new user asks me to use the infrastructure of the > website to create a new registration for his handgun shop because he > wants to know the amount of arms that have to be taken from the > factory. > So, I, as the site admin, adding 2 new record to the Details table > (caliber and shell capacity), and a new record to the registration > table. This is very simple and can be done from the admin site. > > The problem is that I need to change the code (models.py) and add a > new model called "Handgun"- a model for the registration that has > those columns: > Foreign key to Registration table, Shell capacity, Caliber Capacity. > > I don't want to change the code (models.py) whenever I'm adding a new > registration record. this attitude is bad and not scalable. > > I'm need your advice! > > On Oct 14, 6:30 pm, Stuart wrote: > > > > > > > > > Hello omerd -- > > > If you give some concrete examples of what you are trying to do, > > including providing your current models.py code, it will make it > > easier for us to help you. > > > Since you have Registration and Details models, I am assuming you want > > the user to be able to create/define these items, rather than > > specifying them yourself beforehand. So if I am a user of your system, > > I can define a new Registration for handguns, and indicate that I want > > Details of caliber and shell capacity. Then another user can access > > the system and register his .38 six-shooter. Is that the kind of thing > > you have in mind? If so, you are essentially giving the users the > > ability to define a new table (Registration) with certain columns > > (Details), and then letting them populate it (and you would store the > > actual values using another model like 'AttributeValue'). > > > On the other hand, if you are defining the subjects beforehand as the > > developer, you will want a different approach altogether. In that case > > you might consider something like model inheritance (https:// > > docs.djangoproject.com/en/1.3/topics/db/models/#model-inheritance) or > > some other technique to keep things DRY as you add dozens of > > registration subjects. > > > Hope that helps, > > > --Stuart > > > On Oct 14, 6:53 am, omerd wrote: > > > > Hello everybody, > > > I am writing my first web application with Django. > > > > I want to create a web of registration for many subjects. > > > However, each subject require different set of details to be supplied > > > so I don't know which models should I have in the database. > > > > Currently I have two models: > > > Registration - describes a registration (each record is a different > > > subject) > > > Details - describes all the possible details which may be necessary to > > > register. > > > > Now, each Registration instance should contain a list of the necessary > > > details, so i guess that Registration and Details are Many-To-Many > > > connected. > > > > My question is - how the other model(s) which contains the actual > > > details and a FK to Registration model should look like? I don't want > > > to create a new model for each Registration record and place the > > > necessary details hardcoded in the model fields. What if I have 30 > > > records in Registration table ?! -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django models design question
Thank you for the response. As stuart wrote, i should give more details about the website. Currently let's suppose I have 2 interesting tables (I'm not sure that the relationship between these 2 tables is well designed): 1. Details, that contains all the possible information that should be provided to register for something. For example: first name, last name, phone number, address etc. I should mention again that every registration needs other set of details 2. Registration, that have the following columns: admin (the admin of the registration), registration_name,id , foreign key to Details(many to many). actually, I chose the first model that sturat described. I wan't that some users that have the appropriate privileges (super-user) will be able to define new registration for something. For example, let's suppose that a new user asks me to use the infrastructure of the website to create a new registration for his handgun shop because he wants to know the amount of arms that have to be taken from the factory. So, I, as the site admin, adding 2 new record to the Details table (caliber and shell capacity), and a new record to the registration table. This is very simple and can be done from the admin site. The problem is that I need to change the code (models.py) and add a new model called "Handgun"- a model for the registration that has those columns: Foreign key to Registration table, Shell capacity, Caliber Capacity. I don't want to change the code (models.py) whenever I'm adding a new registration record. this attitude is bad and not scalable. I'm need your advice! On Oct 14, 6:30 pm, Stuart wrote: > Hello omerd -- > > If you give some concrete examples of what you are trying to do, > including providing your current models.py code, it will make it > easier for us to help you. > > Since you have Registration and Details models, I am assuming you want > the user to be able to create/define these items, rather than > specifying them yourself beforehand. So if I am a user of your system, > I can define a new Registration for handguns, and indicate that I want > Details of caliber and shell capacity. Then another user can access > the system and register his .38 six-shooter. Is that the kind of thing > you have in mind? If so, you are essentially giving the users the > ability to define a new table (Registration) with certain columns > (Details), and then letting them populate it (and you would store the > actual values using another model like 'AttributeValue'). > > On the other hand, if you are defining the subjects beforehand as the > developer, you will want a different approach altogether. In that case > you might consider something like model inheritance (https:// > docs.djangoproject.com/en/1.3/topics/db/models/#model-inheritance) or > some other technique to keep things DRY as you add dozens of > registration subjects. > > Hope that helps, > > --Stuart > > On Oct 14, 6:53 am, omerd wrote: > > > > > > > > > Hello everybody, > > I am writing my first web application with Django. > > > I want to create a web of registration for many subjects. > > However, each subject require different set of details to be supplied > > so I don't know which models should I have in the database. > > > Currently I have two models: > > Registration - describes a registration (each record is a different > > subject) > > Details - describes all the possible details which may be necessary to > > register. > > > Now, each Registration instance should contain a list of the necessary > > details, so i guess that Registration and Details are Many-To-Many > > connected. > > > My question is - how the other model(s) which contains the actual > > details and a FK to Registration model should look like? I don't want > > to create a new model for each Registration record and place the > > necessary details hardcoded in the model fields. What if I have 30 > > records in Registration table ?! -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Django models design question
Hello everybody, I am writing my first web application with Django. I want to create a web of registration for many subjects. However, each subject require different set of details to be supplied so I don't know which models should I have in the database. Currently I have two models: Registration - describes a registration (each record is a different subject) Details - describes all the possible details which may be necessary to register. Now, each Registration instance should contain a list of the necessary details, so i guess that Registration and Details are Many-To-Many connected. My question is - how the other model(s) which contains the actual details and a FK to Registration model should look like? I don't want to create a new model for each Registration record and place the necessary details hardcoded in the model fields. What if I have 30 records in Registration table ?! -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
