-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for CUSTOMER ACCOUNT LOG ENTRIES on a CUSTOMER ACCOUNT #137
base: next
Are you sure you want to change the base?
Conversation
…dded CustomerRegistration and CustomerDeregistration as 2 first LOG ENTRIES
Will create CR if required; per response to #136 (comment) |
@nick-knowles @skinkie @Aurige Any review? |
This is really not my speciality... but if required I'll dig in. |
looks ok, however you are mentioning TM5 as reference, is it a type ? TM6 has largely reviewed LogEntries (and we will go much deeper with them in NeTEx when OpRa work will start next year) |
My mistake, in it is TM6, but part 5. Location 978 on page 134. Doc CEN/TC 278 1 |
Ok no pb... that's something on which I would like to have @nick-knowles and Kasia's input... that definitely makes sense, it is just not yet in NeTEx... Also we are clearly entering in OpRa scope (NeTEx is expected to be about planed information) |
…o log passengers trying to validate an account with 0 or more unused access rights but without success
Probably to be rerouted to "Next" |
@Aurige merge? |
I would prefer to have @nick-knowles point of view before |
What is the status of the OpRA work @Aurige ? |
@Aurige any update on this? |
@seime you mean this PR or OpRA ? For OpRA we hope to launch the Work Item for the exchange format this year (Data4PT is going to have a direct discussion with the Commission to make sure it is not going to be postponed again at CEN level). |
In general it is true that we could usefully populate in NeTEx more of the hierachy of specific subtypes of LOG ENTRY from TM6, in particular where we need capture additional attributes that are specific to a specific type of log entry (Otherwise one could just use the generic FARE CONTRACT ENTRY with a TYPE OF LOG ENTRY to classify it. ) , To date we have assumed that because of the large volumes of transaction data people would some different, highly optimised forma to exchange such data, but that may be an out of date assumption. ALso we need input as to the specific attributes The abstract CUSTOMER ACCOUNT ENTRY, and specific CUSTOMER REGISTRATION LOG ENTRY / DEREGISTRATION LOG ENTRY are ENtur's initial requirements/ examples (Both subtypes of the hierarchy LOG ENTRY/ FARE CONTRACT ENTRY/ CUSTOMER ACCOUNT ENTRY) , but it would probably be sensible to implement the whole gamut so as to get an uniform implementation. A CR with the [propose attributes would be a good idea. As I understand it from their example , the ENtur example also proposes two additional CUSTOMER ACCOUNT LOG ENTRies log entries that are not in TRansmodel (?) i) InsufficientAccessRightsOnAccount (i.e. an attempt to travel with some, but insufficient rights? ii) NoAccessRightsOnAccount - ie an illegal attempt to travel without rights However, I note that the TM Control and Validation model (which is concerned with monitoring access rights during travel) already defines a different subtype type of FARE CONTRACT ENTRY , a VALIDATION ENTRY, to explicitly record the validation of rights Y. Each individual parameter that has been checked can be recorded as a more detailed VALIDATION ELEMENT. Both succesful and failed validations can be recorded. AN OFFENCE can be used to record further details about an attempt to travel with insufficient rights In general the CUSTOMER ACCOUNT ENTRY is intended for events relating to the creation and maintenance of the account itself, whereas VALIDATION ENTRies are intended to record travel events and the consumption of rights. But.... Having said that, the control and validation model has not been implemented yet in NeTEX ,either . It would probably be better to implement it and use a VALIDATION ENTRY instead of addidng the overlapping entur InsufficientAccessRightsOnAccount / NoAccessRightsOnAccount as this allows the control parameters, CONTROL ENTRY , etc to be captured too , and upholds the TM model. A concrete implementation could have an attribute for summary status insufficient/norights. However, the entur proposal does highlights a gap in the current mode,; it is also necessary to add an association between a VALIDATION ENTRY and a specific CUSTOMER ACCOUNT, so that the entries relating to the specifc CUSTOMER ACCOUNT can be found (to handle thecase where the FARE CONTRACT has more than one account associated with it) PS There is probably a further housekeeping CUSTOMER ACCOUNT ENTRY missing - INVALID VERIFICATION ATTEMPT , so that repeated Hacking attempts to use an account can be detected. |
It was discussed in meeting 3 and it was mentioned that we already have a FareContractEntry that may be used for this. Also ENTUR said that they will rework the PR and finally dropped it (when Arne left). |
@nick-knowles to update the PR (or create a new one) |
Have to be little careful here as to what is or isnt in Netex. Validation and control isnt. There are some thimngs we could do eg alowing a direct reference between CUSTOMER PURCHASE PACKAGE and FARE ENTRies for convenience (can derive this from other relations but a pain in NETEx as that means of the stuff has to be exchanged |
Probably to postpone to 3.0 (to be checked by ENTUR) |
Currently there is a
LogEntry
extension hierarchy likeLogEntry -> FareContractEntry -> SalesTransaction/TravelSpecification
etc. This pertains to things that happen on a FARE CONTRACT.In TM6 part 5 CUSTOMER ACCOUNT USE EVENTS (chapter 5.10.6.2) are described. These events and entries log activity on the CUSTOMER ACCOUNT itself such as registration, deregistration, profile modification etc.
This PR adds another "branch"
CustomerAccountEntry
extendingLogEntry
and the first 2 events mentioned under chapter 5.10.6.2.2.LogEntry -> CustomerAccountEntry -> CustomerRegistration/CustomerDeregistration
More LogEntries will be added as separate PRs later if this PR is merged.
Excerpt from TM6 part 5 page 134: