Testing and upgrades · SmartERP Documentation

What the automated tests of the nine Planning modules cover, how to run them, and the upgrade and migration notes for each version.

This page is a reference for developers and release managers. It applies to SmartERP Planning 17.0.3 and the bridge modules at 17.0.1 and 17.0.2.

Running the tests#

All tests are tagged post_install and -at_install, so they run after the modules are installed. Run them on a copy of a database, never on live data:

odoo -d TESTDB -i smarterp_planning --test-enable --test-tags /smarterp_planning --stop-after-init

Install the bridges you want to test in the same command and select them with their own tags, for example -i smarterp_planning,smarterp_planning_project --test-tags /smarterp_planning,/smarterp_planning_project. The bridge tests import the shared fixtures from smarterp_planning.tests.common, so Planning must be installed.

The shared fixture PlanningCommon builds a UTC calendar of 08:00-12:00 and 13:00-17:00 on weekdays (a Monday 08:00-17:00 shift is 9 clock hours and 8 working hours), two roles (Chef 20 per hour, Waiter 12), a manager, two Planning users and an internal user, four employees with roles, and a Monday at least a week ahead so that every shift is in the future.

What the tests cover#

146 tests in total. Counts per file:

Module	File (tests)	Covers
Core	`test_shift.py` (16)	Working hours from the calendar, percentage and hours, time off, shifts outside the calendar, open shifts, role defaults, end before start, overlaps, publication warning, publish email, templates, save as template, properties.
Core	`test_planning_features.py` (19)	Breaks, wrong role, forecasts, split, duplicate, Plan with Template, spreading hours, grouped reports, qualified count, Auto Plan explanations, the rota grid.
Core	`test_operations.py` (8)	Copy Previous Week (with conflicts and recurring shifts), Auto Plan (default role, spreading, time off, shifts that cannot be filled, republication flag), Publish and Send.
Core	`test_self_service.py` (11)	Taking, role and busy checks, unassigning and its deadline, switch requests, direct writes.
Core	`test_security.py` (8)	What each level sees, create and delete limits, multi-company, roles and templates read only.
Core	`test_schedule_api.py` (13)	Rows, workload, forecast netting, unavailability, card actions, drop checks, undo, copy-to, bulk actions, header actions, quick create, To plan.
Core	`test_recurrence.py` (7)	Repetition types, horizon, cron extension, editing this and following, editing all, stopping.
Core	`test_notifications_capacity.py` (10)	Reminders, broadcast, daily limit, approval, utilisation refresh and rules, dashboard counts.
Core	`test_portal.py` (7)	The pages, wrong or missing tokens, week grid and switch flow with real CSRF tokens, navigation, expiry, first-come broadcast.
Core	`test_assets.py` (1), `test_localisation.py` (1)	The backend bundle builds with the timeline; the Amharic terms load.
Time Off	`test_holidays.py` (3)	Pending and approved leave, notes, Auto Plan, other days.
Contracts	`test_contract.py` (3)	Shifts after a contract end, people without contracts, Auto Plan.
Skills	`test_skills.py` (4)	Auto Plan, flags and filters, self-service refusal, templates.
Attendances	`test_attendance.py` (3)	Late and early leave, no-show, missed-start alert.
Project	`test_project.py` (5), `test_project_planning.py` (8)	Project and task links, figures, recurrence and copies, per-project templates, task hours with sub-tasks, the Plan dialog, project manager rights and approval, forecast netting, the overview panel, the To plan panel.
Sales	`test_sale.py` (11)	Open shifts from an order, unit conversion, assigning, idempotence, cancel, product checks, quantity changes, Plan Orders, the role's services.
Timesheets	`test_timesheet.py` (7)	Effective hours, tasks, lines linked to shifts, ambiguous lines, draft timesheets and project override.
SMS	`test_sms.py` (1)	SMS only when enabled and a mobile is known.

Not covered by automated tests: the front-end behaviour of the timeline (dragging, keyboard, dialogs), the printed rota as a PDF, email delivery, and the dashboard drawing. The first-use tour is defined but is not run as a tour test.

Versions and upgrade notes#

Module	Version	Notes
`smarterp_planning`	17.0.3.0.0	See below.
`smarterp_planning_project`, `_sale`, `_timesheet`	17.0.2.0.0
`smarterp_planning_holidays`, `_contract`, `_skills`, `_attendance`, `_sms`	17.0.1.0.0

17.0.1.0.0 to 17.0.2.0.0 (core)#

A migration script runs before the new models load and another after.

Before. The model smarterp.planning.unavailability is gone (time off now comes from resource calendars and Time Off). Its table is renamed to smarterp_planning_unavailability_legacy, so the declared unavailability is kept; drop it yourself once you no longer need it. Shifts were planned against employee_id or workcenter_id; they are mapped to resource_id through the employee or the work center. States change: cancel becomes archived draft; pending, approved and done become published.
After. Role qualifications move from the old employee relation table to the resource table. The placeholder note "New Shift" is cleared. Fields derived from the resource are recomputed. Each planner's earlier allocated hours are restored as a percentage of working hours, and the column phase1_allocated_hours is dropped.

17.0.2.0.0 to 17.0.3.0.0 (core)#

Adds allocation type, change approval state, breaks, shift managers, reminders and the utilisation table. New columns take defaults (allocation type planning, approval none, no break; shift managers are computed from departments). A post-migration script fills the utilisation table for the rolling window with _cron_rebuild, which can take a while on a large database.

Timesheets 17.0.2.0.0#

Effective hours become stored and come from timesheet lines linked to shifts. The post-migration script links existing lines that have a project, an employee and no shift yet, which recomputes the figures.

Translations#

Each module ships a .pot template and an Amharic draft i18n/am.po. The test test_localisation.py proves that the Amharic terms load and reach menus, field labels and Python messages; it does not prove the wording, which a native speaker has not reviewed. The documentation in this section is in English first.

Before you release#

Run the full test set of all nine modules on a copy of the production database.
Check the scheduled actions are active and that the mail server works; see Configuration.
Take a backup before the upgrade; the migrations rename and drop columns.
Re-run Planning: rebuild utilisation figures after changing working calendars in bulk.