dcc0eebb7d
Systematic-debugging: Konrad reported the project/team popovers showed
no options ('can not see any options') and wheel scroll fell through to
the page instead of scrolling the dropdown.
Root cause chain:
1. The 0bbf2ca/ffb3ef6 CSS on .filter-popover had `overflow: hidden`
(to hide anything past max-height) and the body had
`overflow-y: auto; flex: 1 1 auto`.
2. Choices.js renders its option list with the default
`.choices__list--dropdown { position: absolute; }`.
3. Absolutely-positioned elements do NOT contribute to an ancestor's
scrollHeight, so the body's overflow-y: auto never created a scroll
context — wheel events bubbled to the page.
4. The dropdown extended past the popover's bottom edge and got clipped
by the popover's overflow: hidden, so no options were visible.
Single-point fix:
- Remove `overflow: hidden` from .filter-popover (it was only there to
enforce the sticky footer, which the flex layout already does).
- Scoped CSS override on .choices__list--dropdown inside .filter-popover
to force `position: static` — dropdown now flows inline, the body
grows to contain it, and the sticky footer pushes below naturally.
The dropdown gets its own `max-height: 260px; overflow-y: auto` for
long option lists, which gives a clean internal scroll.
Specificity gotcha: Choices.js's rule is
`.choices__list--dropdown, .choices__list[aria-expanded]` — the second
branch has class+attribute specificity (0,0,2,0) that TIES with a naive
two-class override, and since Choices.js's stylesheet loads after ours,
source order gave them the win. The fix is to mirror the selector list,
lifting our specificity to (0,0,2,1) on the aria-expanded branch, which
wins cleanly without `!important`. Inline comment in custom.css explains
this for future reference.
Scoping: the override is gated to `.filter-popover` descendants, so
Choices.js widgets elsewhere in the app (worker / team / project picker
on edit pages, payroll modals, etc.) keep their default absolute-
positioned dropdown.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Flatlogic Python Template Workspace
This workspace houses the Django application scaffold used for Python-based templates.
Requirements
- Python 3.11+
- MariaDB (or MySQL-compatible server) with the credentials prepared by
setup_mariadb_project.sh - System packages:
pkg-config,libmariadb-dev(already installed on golden images)
Getting Started
python3 -m pip install --break-system-packages -r requirements.txt
python3 manage.py migrate
python3 manage.py runserver 0.0.0.0:8000
Environment variables are loaded from ../.env (the executor root). See .env.example if you need to populate values manually.
Project Structure
config/– Django project settings, URLs, WSGI entrypoint.core/– Default app with a basic health-check route.manage.py– Django management entrypoint.
Next Steps
- Create additional apps and views according to the generated project requirements.
- Configure serving via Apache + mod_wsgi or gunicorn (instructions to be added).
- Run
python3 manage.py collectstaticbefore serving through Apache.