Skip to content
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

Open
wants to merge 3 commits into
base: next
Choose a base branch
from

Conversation

seime
Copy link
Contributor

@seime seime commented Dec 9, 2020

Currently there is a LogEntry extension hierarchy like

LogEntry -> 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 extending LogEntry 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:

CUSTOMER ACCOUNT ENTRies record actions by the TRANSPORT CUSTOMER (that is, CUSTOMER ACCOUNT EVENTs) to set up or modify the account of a customer. Note that an account may pre-exist and be used for other transactions than the purchase of travel.

  • A CUSTOMER REGISTRATION ENTRY records the registering of a customer and the creating of an account.
  • A CUSTOMER DEREGISTRATION ENTRY records the clearing of all personal details of a customer and the closing of an account.

@syversenkr
Copy link
Contributor

Will create CR if required; per response to #136 (comment)

@seime seime marked this pull request as ready for review December 9, 2020 10:55
@seime
Copy link
Contributor Author

seime commented Dec 15, 2020

@nick-knowles @skinkie @Aurige Any review?

@skinkie
Copy link
Contributor

skinkie commented Dec 15, 2020

This is really not my speciality... but if required I'll dig in.

@Aurige
Copy link
Contributor

Aurige commented Dec 16, 2020

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)

@seime
Copy link
Contributor Author

seime commented Dec 17, 2020

My mistake, in it is TM6, but part 5.

Location 978 on page 134.

Doc CEN/TC 278 1
Date: 2018-07 2
TC WI00278497 3
EN 12896-5:YYYY 4
Secretariat: NEN 5
6
Public transport - Reference data model - Part 5: Fare management

@Aurige
Copy link
Contributor

Aurige commented Dec 17, 2020

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
@Aurige Aurige added enhancement non semantic enhacement: technical enhancement, etc. needs documentation update The NeTEx document needs to be updated labels Aug 18, 2021
@Aurige
Copy link
Contributor

Aurige commented Aug 18, 2021

Probably to be rerouted to "Next"

@skinkie
Copy link
Contributor

skinkie commented Aug 18, 2021

@Aurige merge?

@skinkie skinkie requested a review from Aurige August 18, 2021 09:10
@Aurige
Copy link
Contributor

Aurige commented Aug 18, 2021

@Aurige merge?

I would prefer to have @nick-knowles point of view before

@seime
Copy link
Contributor Author

seime commented Sep 23, 2021

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)

What is the status of the OpRA work @Aurige ?

@seime
Copy link
Contributor Author

seime commented Jan 17, 2022

@Aurige any update on this?

@Aurige
Copy link
Contributor

Aurige commented Jan 17, 2022

@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).
For the PR, I will mail Nick (as said before, I really would feel more comfortable having his review on this ... for me it look Ok).

@nick-knowles
Copy link
Contributor

nick-knowles commented Jan 18, 2022

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

image

image

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.

image

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.

@ue71603
Copy link
Contributor

ue71603 commented Nov 21, 2023

@Aurige Pls discuss and the next meeting, so that @trurlurl may work on it.

@Aurige
Copy link
Contributor

Aurige commented Nov 22, 2023

@Aurige Pls discuss and the next meeting, so that @trurlurl may work on it.

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).
So I think that we can close it, unless you have a use for it

@Aurige
Copy link
Contributor

Aurige commented Dec 14, 2023

@nick-knowles to update the PR (or create a new one)

@ue71603 ue71603 assigned ue71603 and unassigned nick-knowles Apr 10, 2024
@nick-knowles
Copy link
Contributor

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

image

@Aurige
Copy link
Contributor

Aurige commented Apr 16, 2024

Probably to postpone to 3.0 (to be checked by ENTUR)

@ue71603 ue71603 modified the milestones: netex_2.0, netex_3.0 Apr 16, 2024
@ue71603 ue71603 removed their assignment Apr 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement non semantic enhacement: technical enhancement, etc. needs documentation update The NeTEx document needs to be updated
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants