# eventyay-teamshifts: Plugin Setup and Planned Shift Management

> eventyay-teamshifts is an early Python plugin for adding team coordination and shift management to eventyay. It currently bootstraps plugin registration, while its operational features remain documented as future work.

**fossasia/eventyay-teamshifts** — Team shifts plugin for eventyay

- Repository: https://github.com/fossasia/eventyay-teamshifts
- Stars: 1,511 · Forks: 28
- Language: Python
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/fossasia-eventyay-teamshifts

## eventyay-teamshifts Targets Event Staffing Coordination

eventyay-teamshifts addresses a specific gap in event operations: organizing event teams and assigning shifts within eventyay. Its intended users are event organisers who need to define team roles, decide which applicants may participate, place volunteers on shifts, and delegate oversight for particular assignments. The README frames the repository as an initial package that bootstraps plugin registration. That distinction matters because the documented feature list describes the intended system, not a claim that every workflow is already implemented.

The planned scope is broader than a simple volunteer contact list. Team configuration is expected to vary by event and may include whether applications are open, a description, and a capacity. The project also plans member roles with their own names, descriptions, and capacities. That model is intended to represent the hierarchy and responsibilities within an event team before assignments are made.

Application handling is another intended use. The README specifies a public sign-up route under `/teamshifts/event/<org>/<event>/apply/` and an organiser review interface with accept and reject actions. Shift scheduling is planned around a Vue 3 grid editor, while a REST API is expected to handle shifts and assignments. These details define a clear operational problem, but the repository does not provide release notes or published GitHub releases that would establish when the full workflow became usable.

## Plugin Registration Drives the Current Architecture

The current package connects to eventyay through the `pretix.plugin` entry-point group. In `pyproject.toml`, the package is named `eventyay-teamshifts`, requires Python 3.12 or later, and registers `teamshifts` as its plugin entry point. This is a plugin-based integration rather than a separately described standalone scheduling service.

Based on the planned repository layout, responsibilities are divided into familiar Django and eventyay extension points. `apps.py` is assigned the plugin `AppConfig` and `EventyayPluginMeta`. Models are reserved for entities such as `CallForEventTeam`, `EventStaff`, `Shift`, and `ShiftAssignment`. Views, forms, URLs, templates, serializers, and API modules are intended to cover organiser controls, public sign-up, and the shift editor.

The planned frontend is a Vue 3 application stored as built static content. Server-rendered Django templates and organizer views are expected to coexist with API-backed editing. Signals are planned for sidebar navigation and dashboard widgets, while Celery tasks are assigned to notifications. This separation would keep scheduling state in the backend while using the Vue interface for interactive grid editing. However, the README describes that structure as planned, so the presence of a path in this layout does not by itself prove that its associated workflow is complete.

## Installation Starts From an Existing eventyay Environment

The documented setup assumes that a working eventyay development environment already exists. Confirm Python 3.12 or later is available, follow the eventyay getting-started instructions, and clone this repository. The package metadata declares no runtime dependencies, but the README lists eventyay and Redis as requirements. Redis is tied to the planned Celery notification and reminder features.

Clone the plugin with the command documented by the README:

```bash
git clone https://github.com/fossasia/eventyay-teamshifts
```

After changing into the cloned directory, activate the virtual environment used for eventyay development. Install the package in editable mode so local source changes are reflected in that environment:

```bash
uv pip install -e .
```

Apply database migrations before restarting the server:

```bash
python manage.py migrate
```

The next documented step is operational rather than another command: restart the local eventyay server, open the event settings, find the `Plugins` tab, and enable the plugin. The README does not document a standalone command for starting teamshifts. It also does not say that the public application form or shift editor is available immediately after registration, so an administrator should verify each screen against the enabled plugin rather than assuming the planned features are present.

## Tests and Style Checks Define the Current Engineering Workflow

The repository provides a test dependency group and configures pytest for an eventyay Django environment. Its documented test entry point is:

```bash
pytest tests/
```

The pytest configuration sets `DJANGO_SETTINGS_MODULE` to `eventyay.config.settings` and limits discovery to the `tests` directory. The environment section defines PostgreSQL connection variables for local test execution, including a database named `eventyay-db`. Those settings indicate that running the tests requires more than merely installing this package in isolation. A compatible eventyay checkout and its development database configuration must already be available.

Code style is checked with `ruff` and `flake8`. The README says continuous integration runs these checks for every pull request. The following commands perform the documented local checks:

```bash
ruff check --select I .
ruff format --check .
flake8 .
```

Ruff can also sort imports automatically and apply formatting:

```bash
ruff check --select I --fix .
ruff format .
```

For commit-time enforcement, the project points developers to its own hook installation script:

```bash
./.install-hooks.sh
```

These checks establish a contribution workflow, but the README does not state test coverage, compatibility matrix, or which planned features have tests. The existence of the test command should not be read as evidence of functional completeness.

## Celery Features Add Operational Dependencies and Failure Modes

Notifications are one of the clearest cases where teamshifts extends beyond database-backed scheduling. The planned system assigns assignment confirmations and reminders to Celery tasks, while a 24-hour shift reminder would run through Celery Beat. Redis is therefore not incidental to the long-term feature set. It is required if the asynchronous notification workflow is implemented and operated.

This design also creates a real operational boundary. A working web application does not guarantee that emails or reminders will be delivered. The eventyay Redis configuration, Celery worker, Celery Beat process, and email delivery path would all matter. The README does not document worker startup commands, queue names, scheduling settings, retry behavior, failure reporting, or how failed notifications are surfaced to organisers. It is therefore unsafe to infer delivery guarantees from the feature list.

Capacity enforcement has another constraint. Team member roles and teams are planned to have capacities, and shift assignment is expected to enforce those limits. The repository excerpt does not explain what happens when staff are assigned twice, when capacity changes after assignments exist, or whether conflicts across shifts are checked. Those cases need direct verification before relying on the plugin for staffing decisions.

## License, Releases, and Upgrades Need Direct Repository Checks

The repository is licensed under `Apache-2.0`, both in the license metadata and in `pyproject.toml`. That identifier tells integrators which license text applies, but this review does not provide legal interpretation or advice. Teams combining the plugin with eventyay should review the actual `LICENSE` file and their own distribution obligations.

The repository has no GitHub releases, so there is no documented release artifact or version history available from that source. Versioning is dynamic in `pyproject.toml`, with the value read from `teamshifts.__version__`. Because the README calls the package initial and repeatedly labels substantial functionality as planned, an upgrade cannot be evaluated through a stable release sequence described here. Reviewing the default `dev` branch, plugin registration, migrations, and eventyay compatibility would be necessary before adopting unreleased work.

The last push was on 2026-10-16, and the repository is not archived. That is the only maintenance evidence available. No claim about release cadence, backward compatibility, migration stability, or long-term support can be made from that push date alone.

## Plugin Development Differs from a Separate Staffing System

The practical alternative is a separately hosted staffing application connected manually to eventyay data. Such a system would follow a different approach: organisers could use a dedicated interface for applications and shifts, then transfer or synchronize relevant assignments with eventyay. teamshifts instead follows an embedded plugin model, using eventyay's plugin registration and planned routes, controls, templates, and APIs inside the host application.

The embedded approach can avoid treating teamshifts as a standalone deployment, but that expectation depends on feature completion and host compatibility. The separate-system approach introduces its own synchronization and identity problems, and the repository provides no connector for evaluating that trade-off. The documented teamshifts design is still preferable when event-specific team configuration and direct host integration are the main requirements, provided the planned workflows are already present in the code being evaluated.

## Conclusion

Adopt this plugin only if you are willing to evaluate and complete an early eventyay integration, particularly when team roles, applications, and capacity-controlled shift assignment are on your roadmap. Do not treat it as a ready replacement for an established staffing system based on the current documentation. Verify the implemented feature set in the installed eventyay instance, confirm Python 3.12 and Redis compatibility, and inspect whether a missing migration or Celery worker prevents the workflows you need.

## FAQ

### What is eventyay-teamshifts used for?

It is an eventyay plugin intended to support event teams, role management, applicant review, shift scheduling, staff assignments, and related notifications. The README describes much of that scope as planned rather than fully delivered.

### How do I install eventyay-teamshifts?

Start with a working eventyay development setup, activate its virtual environment, install the plugin with `uv pip install -e .`, and run `python manage.py migrate`. The plugin is then enabled from the `Plugins` tab in event settings after restarting the server.

### Does eventyay-teamshifts include shift scheduling and email reminders?

Shift scheduling, assignment confirmations, reminders, and a 24-hour Celery Beat reminder are listed as planned features. The README does not provide release notes confirming their current completion status.

## Sources

- [fossasia/eventyay-teamshifts on GitHub](https://github.com/fossasia/eventyay-teamshifts)
- [Issues](https://github.com/fossasia/eventyay-teamshifts/issues)
- [License: Apache-2.0](https://github.com/fossasia/eventyay-teamshifts/blob/dev/LICENSE)
- [README](https://github.com/fossasia/eventyay-teamshifts/blob/dev/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fossasia-eventyay-teamshifts