vitorfs/parsifal

Parsifal is a single Django monolith organized as a set of domain apps around one central workflow: planning, conducting, and reporting systematic literature reviews. The repository is not split into services; instead, the architecture is a layered Django project with shared settings, shared templates/static assets, and app-specific models/views/templates.

The top-level project layer lives under parsifal/ and provides the Django bootstrap: settings/ for environment-specific configuration, urls.py for route composition, and wsgi.py for deployment. The README and scripts show typical production packaging through Gunicorn + Nginx + Supervisor, with PostgreSQL as the primary database and SQLite supported locally.

The core business boundary is the reviews app, which acts as the hub for review lifecycle management. It owns the review list/create/detail screens and then delegates into subdomains under reviews/planning, reviews/conducting, reviews/reporting, and reviews/settings. This structure is important for diagramming because the review workflow is intentionally segmented by phase rather than by technical layer.

reviews/planning models and UI cover protocol definition: research questions, PICOC/keywords, inclusion/exclusion criteria, data extraction fields, quality assessment questions, search strings, and sources. Its templates and JavaScript indicate a rich server-rendered interface with client-side enhancement for editing review protocol artifacts.

reviews/conducting is the operational phase where studies are imported, searched, screened, deduplicated, and assessed. The templates and JS files show separate screens for importing studies, search results, study selection, duplicate detection, article details, data extraction, and quality assessment. This is the main transactional path where review data is transformed from protocol inputs into screened studies.

reviews/reporting is the output phase. It packages reporting views and an export module, suggesting generation of downloadable review outputs from the accumulated review data. In an architecture diagram, this is the downstream consumer of the planning/conducting data model.

reviews/settings provides review-level administrative controls such as review settings and delete flows. This is a boundary around lifecycle/configuration operations, distinct from the scientific workflow itself.

authentication and accounts together manage user identity and profile data. authentication contains the custom user/profile model, signup forms, validators, and backend logic; migrations show historical support for external account tokens like Mendeley and Dropbox, plus public email settings. accounts handles profile editing, email preferences, and profile pictures. These modules form the identity boundary for the rest of the system.

invites is a collaboration/access-control subsystem. It manages invite records, email generation, user invite lists, and a “manage access” view, so reviews can be shared with collaborators. For diagramming, this sits between authenticated users and review ownership/permissions.

library is a separate document management area for folders, documents, and shared folders. It has its own models, forms, views, templates, and JavaScript, so it should be shown as an adjacent authenticated workspace rather than part of the review workflow. It likely serves as a personal/shared reference repository for researchers.

blog, help, and core are the public-facing content areas. core provides home/about/support pages and shared context processors; blog serves articles and sitemap support; help serves article/category/search content with its own sitemap. These are distinct from the authenticated application and can be drawn as a public content boundary.

A few utility and integration pieces matter architecturally: utils/elsevier/client.py suggests an external Elsevier API integration for study metadata/search; utils/recaptcha.py indicates bot protection on public forms; and utils/ipaddress.py, mask.py, and version.py are shared helpers. The presence of sitemaps.py in multiple apps shows SEO-oriented public content generation.

The UI stack is server-rendered Django templates with per-app static JavaScript and a shared global static layer. Bootstrap 3.4 and jQuery 3.6 are the main client-side technologies, with app-specific JS enhancing forms and dynamic review screens rather than a standalone SPA.

Operationally, the repository includes management commands under core/management/commands for environment/release tasks, plus a test suite organized per app and GitHub Actions workflows for tox, code coverage, and CodeQL analysis. For an architecture diagram, the main flow is: browser requests enter Django, route into the appropriate app, app logic reads/writes PostgreSQL, and certain features integrate with external services or email-based collaboration.