Fix event registry interface workflow
m-reza-rahman opened this issue · 7 comments
The event registry workflow and validation isn't quite correct at the moment. There are the following key bits of data for each event registry:
- Event type
- Event timestamp
- Tracking ID
- Voyage
- Location
Generally speaking cargo goes through these events:
- It's received at the origin port.
- It's loaded and unloaded onto voyages on it's itinerary.
- It's claimed at it's destination port.
- It may go through customs at arbitrary points.
The following are the workflow/validation rules we should implement at the UI layer:
- There is always a tracking ID, type, time, location.
- We should not attempt to issue events against un-routed or claimed cargo.
- A voyage will be assigned only if the event type is either load or unload.
We should fix this before we do our first stable release.
Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
@alexmario74 this is the issue I anticipated you. Let me know if you want to do it
@thadumi fine, I would like to work on this.
Testing the recent change, I am unable to get a load event to work after cargo is received. The only events that show are customs and receive. Can you kindly confirm? I suggest testing the entire typical workflow for a given cargo. I would open and close the dialog after each event registry to test the edge case.
Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
I think I missed one rule here.
I confirm that, right now a cargo can only be received on the origin port.
Maybe that should change after a receiving event was done.
So, first run:
- cargo start and go to the origin port
- CUSTOM
- RECEIVE
- cargo is received and still in the origin port
- CUSTOM
- LOAD
Not sure if UNLOAD is needed here.
It sounds like I need to explain the domain logic a bit more. The application allows for the possibility that cargo is temporarily on a route that does not match it's itinerary. In fact, it is possible cargo can be completely mishandled and received or claimed at the wrong ports. Of course none of this is ideal, but it can happen.
All we need to do in the UI is some very basic data validation, not attempting to validate the itinerary. Does that make things a bit clearer? So in your example, it is OK to receive cargo into a port that is not the origin and load it onto a voyage that is not on the itinerary (although hopefully this does not happen too often).
Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
Ok, thansk @m-reza-rahman it's ok to open a new PR to fix this?
Yes, of course!
Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.