Issues regarding Key inconsistencies and full descriptions.

[MSB89]

We have experienced a couple of issues..

When making document requests in the response data, an inconsistency with type ID EPC has been noticed where the key comes in varying cases. On our end we can use a case-insensitive search but we thought you should be aware.

We were also under the impression that floorplans had Type ID FPO. I'm struggling to find the documentation for this, it could have been raised in a support call. Our requests are showing the type ID as floorPlan. Can you confirm if this is correct or if we should also expect this type ID to vary.

A final issue we are facing is retrieving full descriptions of properties, this is not coming through in the GET properties/{ID} response. Attached is a screenshot from our agents perspective.

Screenshot removed as it contains personal email addresses

Looking at our old code base using the SOAP API this is being retrieved from either AdvertText or Description, Description is present in the new response but contains only the short description as pictured and the AdvertText key does not exist. I believe there is a longDescription key but this is providing an empty string.

Example property IDs: KEL200112 GAL210003 AYR210057

Mark from Galbraith

[github-actions[bot]]

Thank you for taking the time to report a bug. We prioritise bugs depending on the severity and implications, so please ensure that you have provided as much information as possible. If you haven’t already, it really helps us to investigate the bug you have reported if you provide ‘Steps to Replicate’ and any associated screenshots. Please ensure any personal information from the production database is obscured when submitting screenshots. This issue will be reviewed in our weekly refinement sessions and assigned to a specific project board. We may also update the ticket to request additional information, if required. For more information on our processes, please click here

[plittlewood-rpt]

Hi @MSB89 - thanks for reaching out to us. Would it be possible for you to provide some more detail around the issue you mention with the EPC and Floorplan issue, along with some examples?

With regard to your comment on the full description, this can be enabled at a customer level through our extra field semi-structured data mechanism (see https://foundations-documentation.reapit.cloud/api/api-documentation#retrieving-data). If you can confirm specifically which descriptions you need access to through the API, we can get this set up for you. Thanks

[github-actions[bot]]

We have recently requested additional information relating to the issue you have raised. Please can you take the time to review this ticket and where applicable, provide the information requested. For more information on our processes, please click here

[MSB89]

Hi @plittlewood-rpt

These are example properties checked: KEL200112 GAL210003 AYR210057

There was an issue with the screenshot, this long description is the one I'm trying to retrieve:

[MSB89]

Hi @plittlewood-rpt

A further issue we are facing is internally it appears we are uploading brochures in two locations via letters and via property details. Can you confirm which is the correct to retrieve via _links.sellingBrochure. We were under the impression these were from property details but are coming through with LET tags.

[plittlewood-rpt]

Hi @MSB89 - to try and answer everything in this ticket:

• I have enabled the Full Description for Galbraith. You need to explicitly request it when querying GET /properties and GET /properties/{id} by using the extrasField query string parameter. The field you want to request is pAdvertText eg

GET /properties?extrasField=pAdvertText

You shouldn't rely on the document type being set to DET. There is a slight bug in the AGency Cloud system that leaves the type set to LET if it gets added in a certain way. To mitigate this in Platform, you should use the link you've already seen in the _links collection. If you have any issues with this please let me know

I think this covers everything. If you can come back to me I'd be grateful

Thanks

[plittlewood-rpt]

I think the only thing I didn't mention in my previous comment was the floorplan and epc types. Please refer to the Swagger documentation in the Developer Portal (PropertyImageModel.Type which states The type of image (picture/floorPlan/epc/map)). Thanks

[MSB89]

Hi @plittlewood-rpt, sorry could you just clarify which of the two locations (letters or via property details) should be used to retrieve from the _links collection?

[github-actions[bot]]

It looks like you have commented on a closed issue. If your comment relates to a bug or feature request, please open a new issue, and include this issue number/url for reference. For more information on our processes, please click here

[plittlewood-rpt]

The link in the _links collection will always be correct. You can just follow that link to the brochure (as it is set on the Property Details screen). The link will be to the GET documents/{documentId} endpoint, which has a /download subresource providing access to the file itself. Hope this helps

[github-actions[bot]]

It looks like you have commented on a closed issue. If your comment relates to a bug or feature request, please open a new issue, and include this issue number/url for reference. For more information on our processes, please click here

[MSB89]

Hi @plittlewood-rpt first sorry for sticking to this closed ticket, it makes life a little easier to keep eyes on it from our side.

As mentioned we are uploading brochures in two locations via letters and via property details. Our understanding is that Property details is the source of truth for our brochure and accessed via the _links collection. That I think we are happy with the confusion remains on our end however over property types. You said previously not to rely on the type being DET and LET being added due to a slight bug if uploaded in a certain way.

What is the process to avoid LET being set and are there other inconsistencies around how the document type is set or how we should be expecting it? How do we make this more consistent?

We previously spoke to some at Reapit about being able to block LET from the API as they contain a lot of legal documentation etc and we want to cover ourselves from a GDPR point of view so I think that is adding to the confusion.

[github-actions[bot]]

It looks like you have commented on a closed issue. If your comment relates to a bug or feature request, please open a new issue, and include this issue number/url for reference. For more information on our processes, please click here

[MSB89]

@plittlewood-rpt Any chance you could have a quick look at the updates from last week? Got some business pressure to answer those questions.

[github-actions[bot]]

It looks like you have commented on a closed issue. If your comment relates to a bug or feature request, please open a new issue, and include this issue number/url for reference. For more information on our processes, please click here