I am trying to Edit Users Table in Django. I am using Users Table to login or register a users. I have to add a new field name Role in that Table but i can't find any option to edit that existing table in admin section.
i just try to field some files to field out where the code of that existing Table is but did't get it.
is there any way to Edit the Table or I have to Create a New Table and have to create a new method of registration.
i am not expert so it's hard to me understand things.
Well first, the Django admin interface it's just for performing CRUD operations over already existing models, you are not able to change in any way the database tables (at lest not using the "out of the box features") using the admin interface.
Said that in order to do what you want to do, with any model (not just User), you should:
Add the field to the model.
Instruct the admin interface to list this fields along the others.
Now the user model is kind of a special model here so I'll recommend a couple of readings you should complete before go forward with the model User customization.
References (User customization): Substituting a custom User model, Extending the User model.
And for the admin interface ...
Reference (admin interface): ModelAdmin options, special attention here to list_display
Related
I am new to Django.
I am going to build simple register and login fullstack application by using React and Django.
My problem is when I received register request with form data.
Is it ok to create custom table for users?
I am going to create another table related to user table.
So in that case, there must be id in the users.
That's why I am going to create custom table.
Please help me it is good practice.
You can abstract from AbstractBaseUser and then you can customise the user model and to specify it in your settings file.
Please see the django documentation here:
https://docs.djangoproject.com/en/4.1/topics/auth/customizing/#substituting-a-custom-user-model
In Django you can link between multiple table by different relationships depends on what you want like:
OneToOne
ForeignKey
ManyToMany
And by default when you create a model django create a pk field it is ID for table, you can make another field as a primary key for model
When you use one of those relationships django by default use model id to link between them
and you can also create a custom user model to use it
Good luck
I have a Django 3.x web site. There are 3 models, among others, Document, MetaData, MetaDataValue. The MetaDataValue model has a foreign key relationship to the MetaData model.
In a simple world, there would be a foreign key relationship from MetaData to Document. Then the DocumentAdmin would display the MetaData field as a dropdown, filled with the appropriate MetaDataValues. There would also be edit/add (pencil/plus) links next to the dropdown to allow the user to edit/add the MetaDataValue for that MetaData object.
However, one of the requirements for the project was not to define which, or how many, MetaData objects would be associated with a particular Document type until run time. Those associations are through another set of models. Therefore, the Document admin change page adds the different MetaData fields to the change admin page at run time, by looking into the database for which MetaData fields are associated with this type of Document, and then adding them to the fieldset through the get_fieldsets method.
The implication of this design is that one cannot edit/add values to a particular MetaData field on the Document admin change page, because, I assume, Django lost the underlying foreign key relationship between the Document and MetaData models because the fieldset is generated in the admin's get_fieldsets method.
I could add pages of code to show how the MetaData fields are generated at run time, but I don't think that would make the description any clearer. I have looked at the page source and fieldsets generated for the "simple world" example described above above, and cannot see where Django is figuring out when to add the edit/change links to the drop down for a particular foreign key field.
My question, is how can I add the pencil and plus sign to these MetaData fields displayed in the Document admin change page, and give the user to option to add/edit the MetaDataValue for that particular MetaData object? I could just create some Ajax calls and do all the heavy lifting myself, bu I would prefer to leverage as much of the Django infrastructure as possible, and not reinvent more than I have to.
Thanks!
Mark
I found a solution using the RelatedFieldWidgetWrapper. I added this widget wrapper to all my selects that needed the green plus (add) and yellow pencil (edit).
There is too much code to post here, but here is the meat of it. My db table MetaData has the names of all the fields, and MetaDataValue has the values for each metadata field. The metadata is used to describe a document (text, video, image), but there are no FK relationships between the MetaData model and the Document model. The relationship between the metadata and the documents is contained in a JSON field in another table. The MetaData table also has what type of Django field is used for that metadata field. There is also another table that determines which metadata fields apply to which document type (image, text, video). For all the ModelChoiceFields, I add the field and the widget (Select wrapped in a RelatedFieldWidgetWrapper).
elif (metadata_names[i].field_type == MetaData.MODELCHOICEFIELD):
fields[metadata_names[i].name] = forms.ModelChoiceField(queryset=MetaDataValue.objects.filter(metadata_id=metadata_names[i].metadata_id).order_by('value'), required=False, label=metadata_names[i].label, help_text=metadata_names[i].help_text)
# add the green plus (add) and pencil (edit) links to each select field
fields[metadata_names[i].name].widget = RelatedFieldWidgetWrapper(fields[metadata_names[i].name].widget, MetaDataValue._meta.get_field('tag_value'), admin_site, can_add_related=True, can_change_related=True)
if 'documentType_id' in fields:
# Editing/add a new document type seems like a bad idea, as document type is used a lot in the processing logic
fields['documentType_id'].widget.can_add_related = False
fields['documentType_id'].widget.can_change_related = False
The hard part was getting the right arguments for the RelatedFieldWidgetWrapper. The documentation is a little sparse on that widget, because, I think, it was an early part of the admin, but much of the Django code has changed since it was first implemented, so a lot of ways this wrapper was used in the past (ie stack overflow posts) has been deprecated. I just looked at the source, and tried what seemed to be appropriate until it worked. Finally, these articles helped a lot:
RelatedFieldWidgetWrapper
More RelatedFieldWidgetWrapper – My Very Own Popup
How can I remove the add and change buttons from a TabularInline admin field?
I am currently working on expanding https://github.com/suutari/drf-jwt-2fa, which provides two-factor authentication over jwt for rest-framework.
I would like to make the two-factor auth non-enforced; that is, users should be able to choose if they want this extra security.
For that purpose, I would like to add a boolean field (lets call it two_auth) to the user model.
What is the best approach to add this field?
I am currently thinking on some possibilities, but none of them seems to be neat enough:
Create a relation table (user_id, two_auth) without foreign-key enforcement: I should use signals for user deletion
Create a relation table (user_id, two_auth) with foreign-key enforcement: The foreign key should point to the model specified at settings.AUTH_USER_MODEL. I generally like model declaration parameters to be explicit, not patchable.
This is a nice guide on options to extend the built-in user model.
Would it be more efficient to create a custom user model if I want settings to be tied to the user (AbstractUser would be used)?
The other seemingly simpler option would be to create a Settings model in my main app and tie it to the user with a foreign key. Which would be more maintainable when the user-base grows?
Some examples of a few settings options would be private profile, hidden in search, profile pictures.
1. Create a Custom User Model:
You should create a custom User Model extending AbstractUser when you use Django authentication process and need to add some extra information directly in the User model, without having to create another class.
2. Create a Settings Model in my main App and tie it to the User Model with a OneToOneField:
You should use a One-To-One Link as long as you have to store extra information about the existing User Model and it doesn't have anything to do with the authentication process.
Reference: https://simpleisbetterthancomplex.com/tutorial/2016/07/22/how-to-extend-django-user-model.html
I am trying to implement a model where only a subset of the fields should be presented in forms, based on a foreign key in the model.
The total number of fields is relatively low (~20), but may change frequently with different values of the foreign key.
I would like to use something like single table inheritance, but with a single model (no inheritance). I looked at existing packages eav, dynamic models... but they did not seem to fit my needs.
I part of the requirement is that I would like to query the models by sql without too many joins.
Here is a use case representing applications to grants based on a request for application (rfa). The rfa is entered in the admin by staff and the applications are made by end users.
application class
rfa (request for application): foreign key
field_1
...
field_20
rfa class:
app_fields (coma separated list of field names)
In the forms, only the fields in app_fields should be visible for a particular rfa.
I have the rfa part covered with django-separatedvaluesfield and I was wondering how to implement the application pages so that they work with generic views in the frontend and admin, and be DRY.
For the update views, I could have a method in the application model, but it would not work for create as the rfa is not defined for create:
def get_current_app_fields(self):
return self.rfp.app_fields
Any ideas on the best DRY strategy to implement frontend views and admin?
Thanks.