sideabar fixed in dhjanog
This commit is contained in:
@@ -1,14 +1,137 @@
|
||||
# Admin Sidebar Fix - Debug Log
|
||||
|
||||
## Last Change (sidebar_navigation fix attempt)
|
||||
**What I did:** Added `context['sidebar_navigation'] = custom_apps` in `each_context()` method in site.py
|
||||
**Why:** Unfold uses `sidebar_navigation` variable in templates, not `available_apps`
|
||||
**Result:** FAILED - Main group pages show NO sidebar, subpages show default Django sidebar
|
||||
## 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
|
||||
|
||||
|
||||
## Current Fix Attempt
|
||||
**What I did:** Reverted sidebar_navigation override, changed `show_all_applications: True` in settings.py
|
||||
**Why:** Unfold's `get_sidebar_list()` builds sidebar_navigation from SIDEBAR.navigation config. When False, it expects navigation config. When True, it uses available_apps.
|
||||
**Expected:** Custom sidebar shows on all pages using available_apps
|
||||
|
||||
## Root Cause
|
||||
Unfold has two modes: custom navigation (show_all_applications=False) OR auto from apps (show_all_applications=True). We need the second mode with our custom get_app_list().
|
||||
|
||||
Reference in New Issue
Block a user