The Install New Updates module on the admin dashboard lists one-time platform installers that still have pending steps on the site. Clicking the green Check For Updates button refreshes the list — an installer only appears when the site actually has something left to install, and it disappears from the list once its steps are complete.
What Remap API Permissions to new v2 slugs Does
This installer updates saved API permission records so they point at the current v2 API endpoint names. Several endpoints were renamed, and this installer rewrites the stored endpoint paths from the old names to the new ones. It only rewrites the endpoint path on each permission row; the per-row allow and deny decisions are preserved.
It works on the bd_api_key_permissions table and remaps these four endpoint path prefixes:
- /api/v2/category/ becomes /api/v2/list_professions/
- /api/v2/business_data_task/ becomes /api/v2/business_data_api_task/
- /api/v2/forms/ becomes /api/v2/form/
- /api/v2/tags_data/ becomes /api/v2/tags/
If the site does not have the bd_api_key_permissions table, the installer has nothing to migrate and skips.
Why It Appears
The installer counts the permission rows whose endpoint_path still starts with one of the four old prefixes above (it calls these orphan rows). It appears whenever that count is greater than zero, meaning at least one saved API permission still references a legacy endpoint name. If the table does not exist, or no rows reference the old slugs, the installer does not appear.
This is a legacy condition tied to API keys configured before the endpoints were renamed. Seeing it does not mean anything is broken; it means one or more of the site's API permission rows still uses the old endpoint names.
Why It Matters
API permissions are matched by endpoint path. When an endpoint is renamed, a permission row still pointing at the old path no longer lines up with the live endpoint, so the allow or deny decision on that row may not apply as intended. Remapping the paths keeps the existing permission decisions attached to the correct, current endpoints. Skipping the installer leaves those rows referencing endpoint names that no longer exist.
How to Run It
- From the admin dashboard, find the Install New Updates module and click Check For Updates.
- If the site has pending steps, Remap API Permissions to new v2 slugs appears in the list. Click Install.
- After it completes, click Check For Updates again. The entry disappears once no rows reference the old slugs.
If Remap API Permissions to new v2 slugs does not appear in the list, the website is already up to date, so there is nothing to do.
After Running
Nothing changes visibly on the website. The API keys and their allow and deny settings are preserved; only the endpoint path recorded on each affected permission row is updated to the new name. The installer reports how many rows it migrated, broken down by each old-to-new prefix.
The installer re-counts the orphan rows before running and remaps only the rows that still reference the old slugs, so it is safe to run even if part of the update was already applied earlier. If no orphan rows remain, it reports that the migration was already applied and makes no changes.
