Manage contributor groups with teams and organisations. Assign roles, restrict project access, and create partner pages for coordinated mapping campaigns.
Use this file to discover all available pages before exploring further.
HOT Tasking Manager uses a two-level structure — Organisations and Teams — to group contributors, own projects, and control who can map or validate. Organisations are the top-level entities that host mapping campaigns and own projects. Teams are groups of users within (or across) organisations that can be assigned specific roles on individual projects. Together these constructs allow coordinators to run everything from small community events to large-scale disaster response operations with fine-grained access control.
Organisations have a many-to-many relationship with users through the organisation_managers join table. Any user listed as a manager of an organisation can:
Create and publish projects under that organisation
Manage teams belonging to the organisation
Invite other managers
Create and link campaigns to the organisation
Managers are not a separate user role at the global level — the organisation_managers table grants management capability scoped to the specific organisation.
A team is a named group of users belonging to an organisation. Teams are the primary mechanism for restricting project access — project managers assign teams to a project with a specific role (MAPPER, VALIDATOR, or PROJECT_MANAGER), and only members of those teams can perform the corresponding actions.
When a team is assigned to a project, it is given one of the roles defined by the TeamRoles enum, stored in the project_teams join table:
Role
Value
What it grants
READ_ONLY
-1
Team members have no mapping or validation rights on the project
MAPPER
0
Team members can lock tasks for mapping on the project
VALIDATOR
1
Team members can lock tasks for validation on the project
PROJECT_MANAGER
2
Team members can manage the project (edit settings, publish, etc.)
A single team can be assigned to a project multiple times with different roles — for example, a team could be both a MAPPER and VALIDATOR team on the same project.
If a project has one or more teams with MAPPER role, only members of those teams (and admins) can map on it. Projects without any mapper team assignment default to MappingPermission.ANY, meaning any logged-in user can map.
Campaigns are thematic groupings that link multiple projects under a shared banner. A campaign has a name, optional logo, optional URL, and a description. Both organisations and projects can be associated with multiple campaigns through many-to-many join tables (campaign_organisations and campaign_projects).Common uses for campaigns:
Grouping all projects responding to a single disaster event
Collecting thematic mapping work across countries (e.g., a global road network campaign)
Representing a partner organisation’s annual mapping goals
Campaigns are managed through POST /campaigns/ and can be listed at GET /campaigns/.
Partners are public-facing pages for organisations and groups running remote mapathons or sustained mapping programmes. A partner record includes:
Field
Description
name
Partner display name
primary_hashtag
Main OSM changeset hashtag used by the partner
secondary_hashtag
Optional secondary hashtag
logo_url
Partner logo
permalink
Unique URL slug for the partner page
mapswipe_group_id
Links the partner to a MapSwipe group for integrated statistics
website_links
Array of labelled URLs pointing to partner resources
current_projects
Free-text or JSON listing active project IDs
The mapswipe_group_id field connects a partner page to the MapSwipe backend (MAPSWIPE_API_URL, defaulting to https://backend.mapswipe.org/graphql/), enabling MapSwipe contribution statistics to be displayed alongside Tasking Manager progress on the partner’s public page.
