Skip to content

Show specific error dialog when task lock fails due to mapping level or team membership - #7282

Open
jaroslav-kubicek wants to merge 1 commit into
hotosm:developfrom
jaroslav-kubicek:fix/7281-specific-lock-task-error-messages
Open

Show specific error dialog when task lock fails due to mapping level or team membership#7282
jaroslav-kubicek wants to merge 1 commit into
hotosm:developfrom
jaroslav-kubicek:fix/7281-specific-lock-task-error-messages

Conversation

@jaroslav-kubicek

@jaroslav-kubicek jaroslav-kubicek commented Jul 2, 2026

Copy link
Copy Markdown

Closes #7281

What

When locking a task for mapping/validation fails because of the user's experience level or team membership, the UI now shows a specific explanation instead of the generic "It wasn't possible to lock this task for you… Check if your user matches the level, role and permissions required by this project."

Why

The frontend LockError component already resolves per-reason messages by SubCode (works for UserNotAllowed, ProjectNotPublished, InvalidTaskState, …), but the backend catch-all branches leaked raw Python enum reprs as SubCodes — e.g. MappingNotAllowed.USER_NOT_CORRECT_MAPPING_LEVEL — which no message key matches, so the generic fallback always rendered. #2191 fixed the backend half of this in 2020 (proper 403 + SubCode instead of a 500); this completes the frontend half and cleans up the SubCodes.

Changes

Screenshot 2026-07-02 at 15 11 57

Backend

  • mapping_service.py: explicit branches for USER_NOT_CORRECT_MAPPING_LEVELUserNotCorrectMappingLevel and USER_NOT_TEAM_MEMBERUserNotTeamMember; defensive fallback now uses a clean MappingNotAllowed prefix instead of the enum repr.
  • validator_service.py: same two branches; fallback renamed ValidtionNotAllowedValidationNotAllowed (typo fix). The old subcode collapsed all remaining validation reasons into one string, so they were indistinguishable client-side.
  • Unit tests asserting the new SubCode prefixes for both services.

Frontend

  • taskSelection/messages.js + locales/en.json: new messages for UserNotCorrectMappingLevel, UserNotTeamMember, and the MappingNotAllowed/ValidationNotAllowed fallbacks — picked up automatically by the existing messages[\${error}Error`]lookup inLockError`.
  • utils/promise.js: removed a stray debug console.log in handleErrors.
  • Tests for the new message resolution and the generic fallback for unknown subcodes.

…evel or team membership

The lock-for-mapping/lock-for-validation catch-all branches leaked raw
Python enum reprs (e.g. MappingNotAllowed.USER_NOT_CORRECT_MAPPING_LEVEL)
as SubCodes, which no frontend message key matches, so users always got
the generic 'It wasn't possible to lock this task for you...' dialog.

Backend now emits clean per-reason SubCodes (UserNotCorrectMappingLevel,
UserNotTeamMember) following the existing convention, and fixes the
ValidtionNotAllowed typo in the validation fallback. Frontend adds the
matching i18n messages so LockError resolves them automatically, and
drops a stray debug console.log in the error handler.

Fixes hotosm#7281

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@sonarqubecloud

sonarqubecloud Bot commented Jul 2, 2026

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Lock-task error dialog shows a generic message instead of the actual reason

1 participant