Offense / Operation Calls
Operation Calls¶
Create an operation call, sign up your own villages and send availability, and follow the operation through planning and execution.
At a glance¶
Product route: /workspaces/{workspace_id}/operation-calls, from Offense → Operation Calls.
Who can open this page: signed-in users in an enabled workspace with verified membership, including owners. Non-owners require active membership and collection; verified owners bypass the individual grant, not entitlement or verification. The HTML page uses this view gate; loading cards and participation requires the current linked Travian account. Sidebar visibility does not authorize an endpoint. This feature is implemented despite its historical template location.
What you see¶
Cards are newest-created first and show title, lifecycle label, owner, joined member count, join deadline and chosen operation days. Open a card for its dashboard. The creation wizard has Operation details, Join period and Availability period steps: operation name, optional description, zero to three Fighting against inputs with roster suggestions, local start/end datetimes, and selected operation dates. There is no call-title, description or alliance editor after creation.
The signup dialog selects available hours, then villages and TS levels. Click or drag across hours. The grid covers each operation day plus the six hours before and after it. These saved hour labels are interpreted as UTC send hours by the planner; they are not converted from browser-local time. The village choices come from current collected Troops Overview data. The strongest offensive village is initially selected; backend ordering breaks equal-strength ties by village name descending after case folding. Choose up to ten villages, TS, Treasury, chiefs, culture-points and opener flags. These are signup overrides, while troop counts remain collected data.
The card offers Edit sign-up for an existing signup in sign-up/preparation; otherwise Joined, Join, Leave, Join not open or Join closed according to account and time. The current client normally prioritizes Edit sign-up while joining is open, so Leave may not appear on that card; the dashboard provides Leave for eligible non-owners. A creator can participate through the same own-account signup flow, but cannot leave the call.
Who fills in each field¶
| Field or data | What it means | Who fills it in | Can it be changed here? | When it updates |
|---|---|---|---|---|
| Call name, owner and lifecycle | Title and optional description come from creation; owner is the creator’s current account name; lifecycle is derived from signup end and saved plan state. | call-owner, signed-in-member, backend-derived | Title/description fixed after creation; lifecycle and owner read-only | Creation and each list refresh |
| Signup time and fighting alliances | Creator chooses signup start/end, 1–21 distinct operation days and up to three fighting-against alliances; roster supplies alliance suggestions. | call-owner, roster-ingest | Creation wizard only; close signup from dashboard | Creation; owner closes signup |
| Joined count and own signup | Count of saved signups and the current account’s saved availability/villages determine the join/edit/leave controls. | signed-in-member, backend-derived | Only own signup; join/leave while open, existing edits in sign-up or preparation | List refresh after signup writes |
| Availability and village configuration | Hourly send slots; 1–10 own collected villages with editable TS, Treasury, chiefs, culture-points and opener flags. Collected troop counts are not edited by signup. | signed-in-member, extension-collected, backend-derived | Own signup; TS/Treasury 0–20, chiefs 0–1000000; flags boolean | Signup options load and save; source captures update village choices |
Calculations¶
Operation lifecycle¶
Calculation ID: operation.lifecycle. Five states from signup time and stored publication/start state.
The textual sequence is Sign-up → Preparation → Ready → In progress → Completed. The checks are ordered: until and including signup end, show Sign-up even before the join period starts. After it ends, no plan or a draft/finalized plan means Preparation. Publishing without a recorded start means Ready. A started published plan proceeds to In progress until strictly after its latest scheduled impact, then Completed. Unknown legacy status follows the last two checks.
Publishing and readiness are separate: all assigned non-owner accounts with commands form the readiness quorum. Publication clears readiness; the backend records the start when that quorum is ready. If it is empty, publishing starts immediately. There is no separate Start button. A published plan that has not started remains Ready even if its scheduled impacts are already past.
now<=signup_ends_at => sign-up; plan_data is None or status draft/finalized => preparation; status published without startedAt => ready; otherwise now>latest impact => completed; otherwise in-progress. Latest impact is max valid lastImpactAt, assignment impactTime and fakeCommands impactTime; absent valid times falls back to end of last operation day.
| Input | Who supplies it | Unit | Optional / fallback |
|---|---|---|---|
| signup_ends_at and operation_days | call-owner | UTC timestamp/date list | Required; Required; no fallback |
| plan_data.status/startedAt/impacts | call-owner, backend-derived | plan metadata | Optional; Absent plan => preparation; absent status preserves legacy in-progress semantics |
| Current time | backend-derived | UTC timestamp | Optional; datetime.now(UTC) |
Output: state label. Precision: Exact ordered state decisions. Rounding: No rounding. Clamp: No output clamp. Timezone: UTC; naive parsed impacts assigned UTC.
Signup boundary equality remains sign-up. Latest-impact equality remains in-progress; completion is strictly later. Unknown/missing plan status is legacy in-progress unless completion time has passed. No operation days and no valid impact yields no completion timestamp.
Canonical source and dependencies appear below. Non-canonical mirrors are independently reviewed and do not guarantee equivalent behavior.
Calculation source references
- Canonical: `src/trapitan/api/routes/web.py` — `_operation_lifecycle`. - Dependency: `src/trapitan/api/routes/web.py` — `_operation_last_impact_at`. - Dependency: `src/trapitan/api/routes/web.py` — `_operation_publish_plan`. - Dependency: `src/trapitan/api/routes/web.py` — `_operation_start_if_ready`. - Non-canonical mirrors: none registered.Used on: Overview, Operation Calls, Operation Dashboard.
Freshness and updates¶
Cards load through the list transport on entry, after successful create/signup/leave/delete actions, and every 60 seconds. This is recorded workspace data, not a live game troop query. Join-period inputs use browser-local datetime and submit UTC ISO timestamps; cards format those instants in browser-local time. Operation dates remain calendar dates. Signup hour strings are UTC in the planner; saved date-only legacy availability expands to 24 hourly slots. The lifecycle uses backend UTC now.
Actions and permissions¶
Who can perform each action / Who can take action: All writes require the verified collection gate, a current linked account and same-origin request. Call ownership is matching the current Travian account name; workspace ownership does not grant call ownership.
| Action | Actor | Permission |
|---|---|---|
| Create operation call | signed-in-member | Verified collection, enabled entitlement, current linked account and same origin; creator becomes call owner |
| Delete operation call | call-owner | Verified collection/current account; owner_account_name must match, same origin |
| Open dashboard | signed-in-member | Verified collection; detail scoped to workspace; privileged dashboard-data separately requires current linked account |
| Join/update/leave signup | signed-in-member | Verified collection/current linked account and same origin; fresh join and leave only within inclusive signup start/end; owner cannot leave; existing signup edits in sign-up or preparation only |
Creator ownership permits deleting the call at any lifecycle; the client requests confirmation. Existing participants may edit their own signup after the join window closes while in Preparation. That does not reopen joining or allow leaving. After publication, signup configuration is locked. Planning and early closure are described in the dashboard guide.
States and edge cases¶
With no calls, the page shows No operations yet. With no collected villages for the current account, signup shows that no Troops Overview villages are available; it cannot save an empty selection. A missing linked account prevents the transport/signup flows. Creation requires a nonblank name up to 120 characters, description up to 1000, signup end strictly after start, 1–21 distinct days with the first on or after the UTC signup-end date, and up to three case-insensitively unique alliances. Suggestions are roster data; the backend also accepts valid free text.
Signup requires at least one exact whole-hour slot in the allowed date windows and 1–10 distinct own collected villages. TS/Treasury must be 0–20; chiefs 0–1000000; CP/opener flags boolean. Closed participation returns a conflict; another account’s ownership is forbidden; missing calls/signups are not found. The client shows creation/signup errors in the dialog and leave/delete failures as alerts. A failed list request renders the same empty state as no calls, without a separate error banner. A Sign-up label before the start date can coexist with Join not open. At the exact end instant joining is still open; after it closes the lifecycle becomes Preparation unless a later plan state applies.
Use the sidebar route for normal entry. The legacy coming-soon alias uses the same template but does not supply the primary page’s full initial context.
Related pages¶
- Operation Dashboard for targets, planning and personal attacks.
- Troops Overview for collected village data.
- Targets for the workspace target registry.
Source references¶
Stable page ID: offense.operations.
Source reviewed: 2026-10-07