Closed mstanton1 closed 2 years ago
@RFK250 to confirm if we can pull back an address from a PID and then advise team so approach can be determined / groomed.
LTSA confirmed we cannot pull the civid address from them. If an enhancement is desired at a later time they noted Civic Address lookup is available through DataBC.
"the LTSA has no association with a civic address. Titled land does include Owner Mailing Address, but this isn’t necessarily the civic address of the property. BC Assessment manages a PID to Civic Address lookup (eValue BC) and I believe we use DataBC for a lookup service in Parcel Map BC Search for the same type of civic address association. The LTSA does not host this data though. Our records are Parcel ID’s for titled land."
@Alireja2 Question for you: if the location information isn't coming from LTSA, then where is the location information coming from? @Kaineatthelab suggests BC Assessment - can you please verify? Thank you!
Hey team! Please add your planning poker estimate with ZenHub @cameron-freshworks @ChasBoucher @dimak1 @doug-lovett @garyfan1
@RFK250 I believe it comes from AMHRPDB.LOCATION table on the mainframe.
@RFK250 I believe it comes from AMHRPDB.LOCATION table on the mainframe.
Thanks @Alireja2 ... @doug-lovett @PatrickAHeath Would this be difficult for you to validate (i.e. validate Ali's understanding of where the location information is coming from)?
@Alireja2 @rfk250 This is a new registration question also now in the RC assets channel. Where does the location lot/parcel/block/distlot information come from for new registrations? It is not in the LTSA API title summary response we will be using to verify the pid.
@doug-lovett Aren't those part of the "Full Legal Description" that we receptive from LTSA web service?
@Alireja2 @RFK250 The legacy mhr is consuming a deprecated soap web service for LTSA integration. We are using a new RESTful API. I am attaching the docs below for reference. From my reading of the LTSA API spec, the new full legal description you are referring to is only available in the pdf format with 2 api calls.
https://app.zenhub.com/files/157936592/34f2ab4c-33e5-4850-84dd-4440ca445b31/download
Rename file below from .txt to .yaml https://app.zenhub.com/files/157936592/b9d8ebc0-a498-4c4e-a0f0-f3a9aca54d98/download
Someone needs to confirm with LTSA that only the PDF format is available for GET /orders/{orderId}/product. We require a JSON formatted response - the equivalent functionality of what is available via the SOAP web service (according to Ali).
@doug-lovett Good sleuthing. I've reached out to LTSA.
@RFK250 reading the spec further, it looks like there is a way to fetch the JSON format with a different endpoint: GET /orders/{orderId}. Here is the description: This service provides the ability to retrieve an order by the order id. The response of this operation includes the order status, order parameters, billing information, ordered product in fielded data (as applicable) and the ordered product href. The ordered product href can be used to retrieve the ordered product PDF file.
I think the "fielded data" will return the information we are looking for when we submit a Parcel Info order type. Sorry for the confusion.
@doug-lovett That sounds promising. I've asked LTSA for a data catalogue as part of my request to them, but maybe you already have a URL for that? I should be able to verify metadata from that.
@RFK250 the equivalent would be the open api spec (.yaml file) I attached above, I do have access to their Swagger spec site as well but you need credentials to view the docs.
@RFK250 the equivalent would be the open api spec (.yaml file) I attached above, I do have access to their Swagger spec site as well but you need credentials to view the docs.
Great! I've taken a stab at the AC for this ticket - @PatrickAHeath and @doug-lovett can you please double-check it for me and update it if you think it needs adjusting? And then I think we can groom this one, correct?
Hey team! Please add your planning poker estimate with ZenHub @cameron-freshworks @ChasBoucher @dimak1 @doug-lovett @garyfan1
@cameron-freshworks
UXA (assuming legal description will come in follow up ticket):
@tlebedovich @cameron-freshworks Legal description is in another ticket, this one is strictly about validating a PID by the existence of that PID in LTSA. If the user feedback (i.e. the second "AND" in the AC) is a blocker, let's scope it out of this ticket and into #13119. They'll still get user feedback for invalid entries.
@ChasBoucher @dimak1 - can someone take this ticket to fix the small typo above and then we can move it to RFQA? We can make a follow up ticket to update contact info if it needs updating later c/c @RFK250 @PatrickAHeath
@tlebedovich let me update it now
Updated, any other updates before I commit the change? @PatrickAHeath @RFK250
@dimak1 Not from me. I'm still not sure where that phone number is from, but I don't think we'll get an answer on that today and I don't want it to hold things up.
@RFK250 thanks. The update is in and should be available in Dev shorty. Moving task back to UXA.
BOOM. Thanks Dima. moving to RFQA with contact info as is for now...
Verified!
When a user enters a valid PID:
When a user enters an invalid PID:
Thanks team! And it was a real team effort on this one. :)
AC
GIVEN I am a staff user or qualified supplier registering a home WHEN I enter a PID in the Location Type for Step 4 THEN The PID is automatically validated by API AND If the PID cannot be validated, I receive user feedback telling me why and directing me to check my data entry
Two approaches - one entails changing MHR Spec vs the other which entails wrapping the LTSA API.
Notes