django-x509 is a Django app for managing certification authorities and x509 certificates used by OpenWISP modules.
Core code lives in django_x509/:
base/contains abstract models and core certificate/CA behavior.models.py,admin.py,settings.py,templates/, andstatic/provide concrete app behavior and UI.- Tests live in
django_x509/tests/andtests/.
- Use
README.rstanddocs/for setup, package usage, and baseline test commands. - Use
.github/workflows/ci.ymlfor CI-tested dependencies, QA/test commands, env vars, and supported Python/Django versions. - Use GitHub issue/PR templates when asked to open issues or PRs.
Follow the DRY principle: do not duplicate information or code across files.
If instructions conflict, repository config and CI workflows win first, docs next, and this file is supplemental.
- Keep changes focused. Avoid unrelated refactors and formatting churn.
- Preserve public APIs, migrations, swappable model behavior, certificate generation semantics, and integration points unless explicitly required.
- Mark user-facing strings for translation with Django i18n helpers in Django code.
- Place imports at the top of the file. Only defer imports when necessary (e.g., Django model imports inside functions or methods where the app registry is not yet ready).
- Avoid unnecessary blank lines inside function and method bodies.
- Update docs when behavior, settings, public APIs, setup steps, or supported versions change.
- Add or update tests for every behavior change.
- For bug fixes, write the regression test first, run it against the unfixed code, confirm it fails for the expected reason, then implement the fix.
- Use targeted tests while iterating, then run the documented full test command before considering the change complete.
- Run
openwisp-qa-formatafter editing when available. - Run
./run-qa-checkswhen present. Treat failures as blocking unless confirmed unrelated and reported. - Prefer in-process tests so coverage tools can measure changed code.
- Preserve object-level permissions and swappable model support when present.
- Be careful with certificate authority state, certificate revocation, serial numbers, extensions, private key handling, admin actions, and migrations.
- Watch for private key exposure, unsafe file paths, weak certificate options, invalid extensions, and secrets.
- Preserve validation around CA material, certificate material, revocation, downloads, and uploaded/generated files.
- Write comments and docstrings only when they explain why code is shaped a certain way. Put comments before the relevant code block instead of scattering them inside it.
- If setup, QA, or tests fail, check docs first, then compare with CI. If commands diverge, follow CI.