microsoft / microsoft/BCApps

[GB] IdealPostcodes provider is unusable through the Postcode Service Manager framework

Open
#11,254 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Team: Finance
Dominant language
AL
Stars
683
Forks
459
Avg merge
3d 26m
Merged PRs (30d)
633

Description

Describe the issue
Reported by a BC partner who tried to integrate with IdealPostcodes as a postcode provider through the Base Application's Postcode Service Manager framework. Two defects in src/Apps/GB/IdealPostcodes make the provider unusable on that path (the app's own page extensions are unaffected — they call the provider directly):

  1. The provider cannot be selected. IPCProvider.Codeunit.al (OnDiscoverPostcodeServices) registers the display name IdealPostcodes in Name and the key IDEAL_POSTCODE_POSTCODE_SERVICE in Value — swapped relative to PostcodeServiceManager.RegisterService and to the other provider (GetAddress.io). Page 9143 "Postcode Configuration Page W1" saves the selected row's Name as the service key, so every subscriber guard (if ServiceKey <> MyServiceKeyTok then exit;) rejects the stored key, PostcodeServiceManager.IsConfigured() returns false, and page 9143's OnOpenPage resets the stored selection to Disabled on every open.

  2. The selected address is never returned. OnRetrieveAddress re-fetches the picked entry via GetAddressDetails from https://api.ideal-postcodes.co.uk/v1/<id> — a route the Ideal Postcodes API does not have (404; we are the API vendor and can confirm it never existed) — and ParseAddressDetail expects fields (address, address2, city, …) the API never returns. Every framework lookup ends with "Failed to retrieve address details."

Expected behavior
Selecting IdealPostcodes on the Postcode Service configuration page persists, IsConfigured() reports true, and confirming an entry on the "Postcode Select Address" page writes that address back.

Proposed fix (implemented, verified live on a BC 28.2 sandbox against the production Ideal Postcodes API)

  • Accept both the token and the (locked) display name as the service key.
  • In OnRetrieveAddress, re-run the search for the entered postcode/city and return the entry matching the selected Address ID (falling back to Display Text) instead of calling the nonexistent endpoint; this also makes the "Remove Organisation Name" setting apply to the written-back address.
  • Remove the dead GetAddressDetails/ParseAddressDetail.
  • Regression test that stores the key exactly the way page 9143 does and asserts IsConfigured().

A PR with this change is ready on branch sergey-idealpostcodes:fix/gb-idealpostcodes-service-key-and-retrieve-address and will be opened once this issue is approved.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with src/Apps/GB/IdealPostcodes/IPCProvider.Codeunit.al and compare OnDiscoverPostcodeServices and OnRetrieveAddress with the GetAddress.io provider and page 9143's stored service key. Review the proposed regression test for the configuration path and verify address selection against the production API behavior. Done means IdealPostcodes remains selected, IsConfigured() is true, and confirming an entry writes the selected address back.

Written by the indexing model from the issue text.

Assessment

Domain
api, backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.