Project Management System
PROMIS
Project and Change Request tracking for the IT team, from the request being raised through scheduling to the work being marked done.
- Role & scope
- Fullstack Developer
- Technology stack
- Next.js · NestJS · MySQL
Context & problem
A Change Request raised to the IT team passes through several teams and several workflow stages before it closes. Every move is a status change, and which move is legal depends on where the request currently sits and who is asking.
Those rules lived in the frontend. A request could be moved into a status it should never have reached, or moved by someone whose role did not permit it.
Users & team
The teams a Change Request passes through, and the requesters waiting on it. Both need the same thing from the system: the current status, who owns the request now, how far along it is — and for that to be trustworthy.
Personal contributions
- Moved Change Request status-transition rules from the frontend to the backend.
- Validated every change against three things: the previous status, the user’s role, and the workflow stage the request is allowed to be in.
- Exposed only validated status through the API.
- Rebuilt the frontend status, owner, and progress displays on top of that validated data.
Architecture & decisions
Next.js on the frontend, NestJS on the backend, MySQL for storage.
A rule enforced in the frontend is a suggestion. It holds only for users going through that interface, on that build, with no direct API call in between. Moving the transition rules server-side made the backend the only thing that decides whether a status change is legal, and left the frontend one job: display what the API says is true.
Key features
- Change Request status transitions validated on the backend.
- Every transition checked against the previous status, user role, and allowed workflow stage.
- Status, owner, and progress displayed on the frontend from validated data only.
Challenges & solutions
No single check is sufficient on its own. Role alone lets a manager push a request through a stage it has not reached. Previous status alone lets anyone advance a request they have no claim on. Workflow stage alone ignores who is asking.
The transition is therefore validated against all three together, before the change is written. A request that fails any one of them is rejected rather than saved and corrected afterwards.
Results
A Change Request can no longer skip a stage or be moved by someone without the right role, because the backend rejects the transition before it is saved.
