[Feature] Allow custom ordering of fields for list, details, create, and edit views

#1143 · open · 0 comments

View on GitHub ↗

maxim-f1

### Checklist - [x] There are no similar issues or pull requests for this yet. ### Is your feature related to a problem? Please describe. Currently, the display order of fields in the admin panel is inherited directly from the order in which the fields are defined in the SQLAlchemy model. This forces developers to either alter their database model definitions solely for UI purposes or accept a suboptimal UI layout. I want to be able to reorder the fields independently for different pages (list, details, create, edit) without modifying the underlying SQLAlchemy model. ### Describe the solution you would like. I would like the fields specified in the existing configuration lists (`column_list`, `column_details_list`, `form_edit_rules`, `form_create_rules`) to dictate the exact display order of the fields on their respective pages, rather than just filtering which fields are shown. For example, if I define the following: ```python class User(Base): id = column(Integer) name = column(String) class UserAdmin(ModelView, model=User): # Instead of relying on the model's field order, # these lists should strictly define the UI order column_list = ['name', 'id'] column_details_list = ['name', 'id'] form_create_rules = ['name', 'id'] form_edit_rules = ['name', 'id'] ``` The fields should be rendered as `name` first, and then `id`, regardless of how they are defined in the `User` SQLAlchemy model. ### Describe alternatives you considered The only current alternative is to reorder the fields directly in the SQLAlchemy model. However, this is not ideal because it impacts the database schema semantics and might conflict with existing database migrations or other parts of the application that rely on the current model field order. It mixes UI presentation concerns with data modeling. ### Additional context This feature would provide greater flexibility in customizing the admin interface without compromising the backend architecture. The proposed solution aligns well with the existing API design by simply changing the behavior of the rule lists from "filtering" to "ordering and filtering".

Comments