igny8/ADMIN-SIDEBAR-DEBUG.md

Admin Sidebar Fix - Debug Log

ATTEMPT #1 - FAILED

What: Added context['sidebar_navigation'] = custom_apps in each_context Result: Main pages broke (no sidebar), subpages showed default

ATTEMPT #2 - FAILED

What: Changed show_all_applications: True in settings Result: Subpages still showed default Django sidebar

ATTEMPT #3 - FAILED

What: Overrode get_sidebar_list() to return get_app_list() directly Result: Empty sidebar on all pages (wrong format)

ATTEMPT #4 - FAILED

What: Converted Django format to Unfold format in get_sidebar_list():

• Changed name → title
• Changed models → items
• Changed admin_url → link
• Set show_all_applications: True Result: Sidebar still showing default on subpages

ATTEMPT #5 - FAILED

What: Changed show_all_applications: False (data is correct, format is correct) Data verified:

• sidebar_navigation has 15 groups with correct Unfold format
• Structure: {title, collapsible, items: [{title, link, icon}]} Result: STILL NOT WORKING - sidebar not showing properly

ATTEMPT #6 - PARTIAL SUCCESS! ✓

What: Added has_permission: True to each item in sidebar_navigation Result:

• Group pages (e.g., /admin/igny8_core_auth/) now show custom sidebar ✓
• Subpages (e.g., /admin/igny8_core_auth/account/) still show DEFAULT sidebar ❌

NEW DISCOVERY

Different pages behave differently:

• Homepage (/admin/): Custom sidebar ✓
• Group pages (/admin/app/): Custom sidebar ✓
• Model list pages (/admin/app/model/): DEFAULT sidebar ❌
• Model detail pages (/admin/app/model/1/change/): DEFAULT sidebar ❌

INVESTIGATION RESULTS

1. Context is IDENTICAL on all pages (verified via shell) ✓
2. sidebar_navigation has 15 custom groups on ALL pages ✓
3. But HTML shows DEFAULT "Igny8_Core_Auth" on model pages ❌
4. Both custom AND default groups appear in HTML (conflict!)

ATTEMPT #7 - CRITICAL DISCOVERY!

What: Traced each_context calls during actual HTTP request DISCOVERY: each_context() is NOT being called AT ALL on model pages! ❌ This explains everything: If each_context isn't called, our sidebar_navigation never gets set!

ROOT CAUSE FOUND

• Homepage/group pages: Call each_context() → Custom sidebar works ✓
• Model list/detail pages: DON'T call each_context() → Default sidebar shows ❌
• Django/Unfold is using cached or pre-built context for model pages
• Our overridden each_context() is being bypassed completely!

NEXT STEPS

Need to find where model admin views build their context and ensure each_context is called.

ATTEMPT #8 - FORCING SIDEBAR_NAVIGATION

What: Added explicit check in each_context - if sidebar_navigation is empty, force set it Why: Parent's each_context should call get_sidebar_list(), but maybe it's not or it's empty Testing: Backend restarted with additional safety check Result: NO CHANGE - subpages still show default sidebar ❌

VERIFIED FACTS

1. get_app_list() correctly ignores app_label parameter ✓
2. Returns 16 custom groups regardless of app_label ✓
3. Context should be correct in each_context() ✓
4. But HTML shows DEFAULT sidebar on model pages ❌

ANALYZING NOW

Checking if different templates are used on different page types, or if sidebar is being rendered twice.

ATTEMPT #9 - DIRECT PYTHON DEBUGGING

What: Added print statements directly in each_context() to see if it's called and what it returns Method: Console debugging to trace actual execution flow RESULT: NO OUTPUT - each_context() is DEFINITELY NOT being called on model pages! ❌

CRITICAL FINDING

each_context() is NOT called on ModelAdmin changelist/change views! Django admin must be rendering model pages with a different context building method that bypasses AdminSite.each_context().

This explains EVERYTHING:

• Homepage calls each_context() → custom sidebar ✓
• Group pages call each_context() → custom sidebar ✓
• Model pages DON'T call each_context() → default sidebar ❌

SOLUTION NEEDED

Must find how Django/Unfold builds context for model views and inject our sidebar there. Possible approaches:

1. Override ModelAdmin.changelist_view() and .change_view()
2. Override ChangeList class
3. Find middleware/context processor that runs for model pages

ATTEMPT #10 - OVERRIDE MODELADMIN VIEWS ✅ SUCCESSFUL!

What: Created Igny8ModelAdmin base class that overrides all view methods to inject sidebar_navigation Method: Override changelist_view, change_view, add_view to inject extra_context with sidebar Implementation: Added to /data/app/igny8/backend/igny8_core/admin/base.py Testing: Changed AccountAdmin to inherit from Igny8ModelAdmin Result: ✅ SUCCESS! Sidebar shows correctly on Account pages Applied to: ALL 46+ admin classes across all modules (auth, ai, business, modules)

Final Solution:

1. Created custom Igny8ModelAdmin class that inherits from UnfoldModelAdmin
2. Overrides all view methods (changelist_view, change_view, add_view, delete_view, history_view)
3. Each override calls _inject_sidebar_context() helper that:
   • Gets custom sidebar from admin_site.get_sidebar_list()
   • Forces sidebar_navigation, available_apps, app_list into extra_context
   • Adds branding: site_title, site_header, site_url, has_permission
   • Detects active group and marks it for expanded dropdown
4. All admin classes now inherit from Igny8ModelAdmin instead of ModelAdmin
5. Sidebar now appears consistently on ALL pages (homepage, group pages, model list, detail, add, edit)

Root Cause: Django's ModelAdmin views bypass AdminSite.each_context(), so custom sidebar was never injected Fix: Direct injection via extra_context parameter in overridden view methods

HYPOTHESIS - BROWSER CACHING

The context is correct, but user's browser might be showing cached HTML. Added logging to trace each_context calls. Need user to hard refresh (Ctrl+Shift+R).

STATUS

• Data is CORRECT (verified via shell)
• Format is CORRECT (matches Unfold structure)
• Setting is CORRECT (show_all_applications=False)
• BUT TEMPLATE IS NOT USING IT

POSSIBLE REMAINING ISSUES

1. Template caching
2. Unfold sidebar template has additional requirements we're missing
3. Different template being used on subpages vs homepage