Features
Tickets
How a request moves from a resident reporting something to the association closing it: the nine states, the two conversations on a ticket, and who can move what.
One ticket is one thing somebody wants dealt with: a violation, an architectural review request, a hazard tree, a streetlight that is out. It carries a state, a category, a history of every move it has made, and two separate conversations.
Filing a ticket
Waiting on setup data- What people expect
- A resident opens the portal, picks what the problem is, and files a ticket.
- Why it does not work today
- The ticket surface is deployed and works. The list of categories a ticket can be filed under is operator data held in the association's settings, deliberately never in code, and it has not been provisioned for the pilot association. With no categories the portal shows an explanation instead of a form, because a form whose submission would be refused is worse than no form. An operator-gated API route to seed the catalogue now exists in the service (`PUT /internal/associations/{slug}/ticket-categories`), but nothing in this website calls it yet, so seeding it today still means a person running a request against the service directly rather than a page in the admin console.
- What to do instead
- Residents should contact the management office directly until the categories are seeded. Managers can still read, transition, assign and comment on any ticket that already exists.
Checked against the code on 2026-09-08. Next review 2026-10-15.
Residents file from the portal. You pick a category, describe what is wrong, and the ticket starts in the new state. You then see it in your own list and can follow it and comment on it. You cannot see another resident’s ticket, and asking for one directly returns a not-found that is identical to the one you get for a ticket that never existed.
Nobody else can file on your behalf
The filing route admits residents only. A manager cannot raise a ticket for you from the console, and neither can a board member. If you telephone the office, they will record it some other way and it will not appear in your portal list.
A ticket is always in exactly one of nine states. Which state may follow which is a fixed table, and a move the table does not contain is refused rather than recorded.
Every legal move
| From | May move to |
|---|---|
| new | needs_info, triaged, rejected |
| needs_info | triaged, rejected |
| triaged | needs_info, dispatched, resolved, rejected |
| dispatched | triaged, in_progress |
| in_progress | awaiting_invoice, resolved |
| awaiting_invoice | resolved |
| resolved | in_progress, closed |
| closed | nothing. This is the end of the record |
| rejected | nothing. This is the end of the record |
- A new ticket cannot be dispatched. Something nobody has classified is how a dead animal report reaches a fence contractor.
- A ticket sent back for more information rejoins at triaged rather than at new, because somebody has already looked at it and that should not be thrown away.
- A triaged ticket can be resolved without any vendor. A question answered is a resolution with no work in it.
- A dispatched ticket can go back to triaged. A vendor who declines puts it back on the manager’s desk without it having to become new again.
- awaiting_invoice exists so that "the work is done" and "the money is settled" stay two different facts.
- A resolved ticket can be reopened, because the resident is the one who finds out it was not actually fixed. A closed ticket cannot. Closing is the act of calling the record final.
Closed and rejected are genuinely final
There is no reopen from either. If something closed turns out to need more work, the honest move is a new ticket that references the old one. That is a deliberate design choice and not a missing button.
| What | Who can | Route |
|---|---|---|
| Read the board and any ticket on it | OperatorManagerBoard | GET /manage/tickets, GET /manage/tickets/{id} |
| Move a ticket to another state | OperatorManagerBoardResident | POST /manage/tickets/{id}/transition |
| Assign a ticket | OperatorManagerBoardResident | POST /manage/tickets/{id}/assign |
| Record a work order reference | OperatorManagerBoardResident | POST /manage/tickets/{id}/workorder |
| Comment where the resident can see it A resident comments through their own portal route instead. | OperatorManagerBoardResident | POST /manage/tickets/{id}/comments |
| Write an internal note | OperatorManagerBoardResident | POST /manage/tickets/{id}/notes |
Two people cannot move the same ticket at once
A transition is arbitrated centrally. If two managers act on the same ticket at the same moment, one succeeds and the other is refused with a message saying so. Nothing is applied twice and no history entry is lost.
| Comments | Internal notes | |
|---|---|---|
| Who can read | Everybody who can see the ticket, resident included | Operator, manager, board |
| Who can write | Operator, manager, board, and the resident on their own ticket | Operator, manager |
| Purpose | Talking to the resident | Staff talking to each other |
The two are stored separately rather than in one place with a flag on some of them. That is worth knowing because it is what makes the promise real: there is no request a resident can make, and no page a developer can build carelessly, that returns an internal note to a resident. The resident-facing code has no way to name where the notes are.
For managers: a comment is visible to the resident
Say it in a note if you would not say it to the homeowner. The distinction is enforced by the system, but which box you type into is still your choice.
A ticket is designed to carry photos and PDFs: JPEG, PNG or PDF, up to 10 MB each. Operators, managers and residents can attach. Board members cannot, which surprises people, so it is worth saying plainly.
Photos and files on a ticket
Shipped, not configured- What people expect
- Attach a photo of the problem to a ticket.
- Why it does not work today
- The two routes that arrange an upload are deployed and gated, and the storage behind them is now wired. As with governing documents, whether they work is a property of the deployment: it must name PROPMGMT_ATTACHMENT_BUCKET, and PROPMGMT_DOCUMENT_BUCKET with it, because the service wires all of its storage or none of it. Where they are unset the refusal is honest about being a deployment state rather than a mistake by the person uploading.
- What to do instead
- On a deployment with its buckets set, attach the photo. Where they are not, describe the problem in the ticket text and email photos to the management office if they matter; a manager can record the detail in a comment so it stays with the record.
Checked against the code on 2026-09-09. Next review 2026-10-15.
Raising a work order
Not built- What people expect
- Send a job to a vendor from a ticket and track it from raised to closed.
- Why it does not work today
- There is no work order surface and nothing that raises one. A ticket does have a work order field, and writing to it records a reference and nothing else. The service never checks that anything exists at the other end of that reference, and the page says so where a manager will read it.
- What to do instead
- Dispatch the vendor the way the association dispatches one today, then paste the reference onto the ticket so the record points somewhere. Move the ticket to dispatched so its state matches what happened.
Checked against the code on 2026-09-07. Next review 2026-12-01.
Every move a ticket makes is recorded with who made it and when, numbered in order with no gaps. Entries are never rewritten and the list can never get shorter. If you need to correct a mistaken move, you make another move; you do not erase the first one.
Still stuck?
That is a fair place to be, and it is usually faster to ask than to keep reading. Your association's management office can tell you whether what you are hitting is a permission, a setup step or a fault. Say what you were trying to do and what the screen said. If it needs changing at the service level, they will bring Vara in.