The Reapit properties data returning from API is with strange property ID of other Office

[hoangnguyentci]

Describe the bug Upon reviewing the response data, we've noticed several discrepancies that require urgent attention:

Properties listed by other estate agents have been included in the response. For example, COL240099 and TOT240025 were erroneously sent under TOL and TOT office, respectively, but are actually listed by Fenn Wright and Barstow Eves. Our client has confirmed that these properties do not belong to them.

The consistency of API response data is compromised. In the latest call, COL240099 no longer appears, while TOT240025 persists along with a new property listed by another agent (ID: LEY200028). There have been instances where properties are missing from the data pull.

While we've only seen this issue with one client so far, we're concerned that it may happen to others. Therefore, I kindly request that this matter be treated as a high priority and please inform us of the estimated timeline for the resolution.

To Reproduce The Reapit properties data returning from API is with strange ID Office id TOL Tottenham Lettings in region Ellis & Co has all properties with ID "TOT-----" Few days ago we have property result IDs COL240099, COL240163, COL240207, COL240308. Today those IDs are disappeared, and another strange property ID LEY200028 is in the property result of Office TOL

• API endpoint: https://platform.reapit.cloud/properties/

• User logs in under Client code: MAC-GTTT

• run API endpoint https://platform.reapit.cloud/properties/?officeId=TOT

or API endpoint https://platform.reapit.cloud/properties/LEY200028

• Result return has:

{
    "id": "LEY200028",
    "created": "2020-06-13T15:46:24Z",
    "modified": "2020-11-14T12:20:11Z",
    "marketingMode": "selling",
    "currency": "GBP",
    "officeIds": [
        "TOT"
    ],
...
}

Expected behaviour Properties API endpoint for Office TOL should return all property IDs "TOT-----", not "COL-----" or "LEY-----"

Screenshots

Device (please complete the following information for web issues):

• Device: API Call on any device
• OS: [e.g. iOS8.1]
• Browser [e.g. Chrome, Safari]
• Version [e.g. 22]

Additional context Add any other context about the problem here.

[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 @hoangnguyentci

I think you may have assumed incorrectly that the property id prefix corresponds to the owning office however this is not the case. Office ownership is dictated by the officeIds collection, and this is what the officeId filter acts on. Properties can move between offices once created so the behaviour you are seeing is correct. It's normal to see properties with a different id prefix to the officeId

Thanks Pete

[plittlewood-rpt]

Closing as per separate email thread.

[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