Feature 103 : Reviewer tags & configurable assignment rules

[JulesBlanchard]

Closes #103

Summary

Adds a flexible assignment control system to ReLiS: project managers can tag reviewers with profile labels (e.g. Junior, Senior, Methodologist) and define rules that the assignment engine respects automatically when distributing papers across screening, validation, QA, and classification.

The whole feature is gated behind a system-wide flag (assignment_rules_enabled), disabled by default — existing installations see no behavior change until an admin opts in via Settings → Assignment Rules feature.

What's new

• Reviewer tags: custom labels (name, description, color) attached to project members, shown as badges on assignment screens, the Participants tab, and the Users list. Three tags seeded by default.
• Assignment rules, 5 types: minimum/maximum reviewers per tag per paper, tag combinations (OR logic), reuse same reviewer from a previous phase, forbid reviewer from a previous phase. Each rule is scoped to an assignment screen and optional phase.
• Feature flag: single admin toggle controls menu visibility (project home Planning only), engine behavior, and UI everywhere at once.

Database

3 new tables per project (reviewer_tag, userproject_tag, assignment_constraint), auto-migrated on existing projects via an idempotent run_assignment_migration_if_needed(). One new admin_config row for the feature flag.

Per-project database (relis_dev_correct_*) — 3 new tables added, no existing table modified:

reviewer_tag

Key	Type	Nullable	Default Value
tag_id	Int	No	Auto Increment
tag_name	varchar(50)	No	\
tag_description	varchar(255)	Yes	NULL
tag_color	char(7)	No	#888888
tag_active	int(1)	No	1
added_by	int	Yes	NULL
added_time	timestamp	No	current_timestamp()

UNIQUE constraint on tag_name (per project).

userproject_tag

Key	Type	Nullable	Default Value
userproject_tag_id	Int	No	Auto Increment
user_id	int	No	\
tag_id	int	No	\
assigned_by	int	Yes	NULL
assigned_time	timestamp	No	current_timestamp()
userproject_tag_active	int(1)	No	1

UNIQUE constraint on (user_id, tag_id).

assignment_constraint

Key	Type	Nullable	Default Value
constraint_id	Int	No	Auto Increment
constraint_scope	varchar(40)	No	\
phase_id	int	Yes	NULL
constraint_type	varchar(60)	No	\
constraint_params	text	No	\
constraint_priority	int	No	100
constraint_active	int(1)	No	1
constraint_enabled	int	No	1
created_by	int	Yes	NULL
created_time	timestamp	No	current_timestamp()

These 3 tables are created via an idempotent migration (run_assignment_migration_if_needed()), which checks for existence before creating anything. Existing projects pick it up automatically on next load — no manual SQL required, no impact on existing project tables (paper, screening_paper, etc.).

System database (relis_db, shared across the whole installation) — 1 row inserted into the existing admin_config table, no column added:

config_label = 'assignment_rules_enabled' — controls the feature flag globally.

The feature ships disabled by default (assignment_rules_enabled = '0'), so every existing project sees zero behavior change until an admin explicitly enables it via Settings → Assignment Rules feature.

The feature ships disabled by default (assignment_rules_enabled = '0'), so existing projects see zero behavior change until an admin explicitly enables it via Settings → Assignment Rules feature.

Tests

Unit test suite 28 passing tests: regression, CRUD, each constraint type, integration scenarios, and engine edge cases (priority, phase scoping, malformed params, workload balancing).

Security

Server-side permission guards added to all new endpoints (can_manage_project, can_review_project, has_usergroup(1)).

Notes for reviewers

• Feature ships disabled by default; enable via Settings → Assignment Rules feature.
• Fresh installs get everything automatically. Existing instances: project-level tables auto-migrate on next project load.