Exercise 1: Plain Registration vs. a Customized ModelAdmin — Possible Solution ==================================================================== WHAT admin.site.register(Item) ALONE PROVIDES ------------------------------ It gives a complete, working, but generic CRUD interface for the Item model - a list view, and add/edit/delete forms - generated automatically from the model's own fields, with the list view showing each row's __str__ representation by default. WHAT A CUSTOMIZED ModelAdmin ADDS ------------------------------ A ModelAdmin subclass shapes that generic interface into something genuinely more usable: list_display chooses which specific columns actually appear in the list view instead of just one generic label per row; list_filter adds a sidebar of quick filters for jumping directly to a subset of records; search_fields adds a real search box performing substring matching against the specified fields; readonly_fields controls which fields are shown as read-only in the change form. WHY THESE MATTER IN PRACTICE, NOT JUST AS NICE-TO-HAVES ------------------------------ Without list_display, the list view only shows one generic label per row, making it hard to scan many items at once for genuinely useful information like status or expiry date. Without list_filter, finding all active items among many requires scanning the whole list manually rather than clicking one filter. Without search_fields, finding a specific item by name or barcode among a large dataset requires scrolling rather than typing a quick search - all real, practical usability gaps that appear the moment there's more than a handful of real rows to manage. WHY THIS WORKS AS AN ANSWER ------------------------------ It correctly describes the baseline CRUD interface plain registration provides, correctly explains what each ModelAdmin option specifically adds, and explains why each one matters for genuine day-to-day usability once real data volume exists, rather than treating them as merely cosmetic options.