Is your feature request related to a problem? Please describe.
Currently, the export_users management command in openwisp-users does not support exporting ForeignKey relations from related objects. While there is special handling for the organizations field, this approach is not sufficient when there is a need to include fields defined in other modules (outside the core openwisp-users domain).
|
elif field == "organizations": |
|
organizations = [] |
|
for org_id, user_perm in user.organizations_dict.items(): |
|
organizations.append(f'({org_id},{user_perm["is_admin"]})') |
|
data_row.append("\n".join(organizations)) |
This limitation is highlighted by the upcoming model changes discussed in openwisp/openwisp-radius#692, where the RegisteredUser model is being updated to support a multi-tenant structure. Specifically, RegisteredUser will now have a ForeignKey to the User model. As a result, it is necessary to provide generic mechanisms or extension points to support exporting custom fields from objects linked through ForeignKeys.
Additional context
This requirement is motivated by openwisp/openwisp-radius#692, where the RegisteredUser model changes will introduce a ForeignKey to the user. Being able to customize how ForeignKey fields from related modules are exported will greatly facilitate multi-tenant and modular setups in OpenWISP.
Is your feature request related to a problem? Please describe.
Currently, the
export_usersmanagement command inopenwisp-usersdoes not support exporting ForeignKey relations from related objects. While there is special handling for theorganizationsfield, this approach is not sufficient when there is a need to include fields defined in other modules (outside the coreopenwisp-usersdomain).openwisp-users/openwisp_users/management/commands/export_users.py
Lines 66 to 70 in 2ef104e
This limitation is highlighted by the upcoming model changes discussed in openwisp/openwisp-radius#692, where the
RegisteredUsermodel is being updated to support a multi-tenant structure. Specifically,RegisteredUserwill now have a ForeignKey to the User model. As a result, it is necessary to provide generic mechanisms or extension points to support exporting custom fields from objects linked through ForeignKeys.Additional context
This requirement is motivated by openwisp/openwisp-radius#692, where the
RegisteredUsermodel changes will introduce a ForeignKey to the user. Being able to customize how ForeignKey fields from related modules are exported will greatly facilitate multi-tenant and modular setups in OpenWISP.