Integrations often come with their own event types — forms that a technology provider defines and maintains as their system evolves. This article walks through setting up a provider's account so they can create and edit event types and choice lists in their own event category, without giving them access to anything else in EarthRanger.

This builds on the general concept covered in Permissions and Permission Sets — if you haven't read that section yet, it's worth a quick look first, since this article assumes you already know what an event category permission set is.

Before you start

• You'll need admin (superuser) access to Django admin to configure permission sets and user accounts.
• The event category the provider will curate should already exist. If it doesn't, create it first — EarthRanger generates the permission set for you automatically.

What you're setting up

A provider account that can edit event types needs four things:

1. Staff access — so the account can reach the event type editor in the admin.
2. The category's generated permission set — this is what scopes editing to just one category.
3. An "Event Type Editor" permission set — three read-only permissions the editor page depends on to load.
4. A "Choice Editor" permission set — permissions to maintain the choice lists (e.g. species, statuses) used on the category's forms.

You'll typically create the Choice Editor and Event Type Editor sets once, then reuse them for any provider or category going forward.

Steps

1. Create a "Choice Editor" permission set

In the admin, create a permission set with these four permissions:

2. Create an "Event Type Editor" permission set

Add these three read-only permissions, and set this permission set to inherit from Choice Editor:

• observations.view_source
• observations.view_subject
• observations.view_subjectgroup

These aren't optional extras — opening an event type in the editor loads sources, subjects, subject groups, and choices together to build the choice-list filter pickers. If any one of these is missing, the page fails with a 403 error.

3. Attach the category's permission set

Every event category has a permission set generated automatically when the category is created, named "View {Category} Event Permissions." Add the provider's account to the set for the category they'll be curating (for example, "View AddaxAI Event Permissions"). Attach one set per category the provider should be able to edit.

Before you attach this: these permissions also grant full create, read, update, and delete access to the events (reports) in that category — not just the event type forms. There's currently no way to grant form editing without event data access in the same category. For a provider whose system is already writing events into that category, this is usually expected — but confirm it's intentional before granting it.

4. Flag the account as staff

Set is_staff to True on the user. Combined with the category permission set from step 3, this makes the "Event Types and Categories" link visible in the admin and opens the editor.

What each permission does

What not to grant

A few permissions look related but don't affect the event type editor. Leaving them out keeps the account's access easy to audit:

• "Can add/change/view event type" — these only apply to the legacy editor and aren't checked by the current event type editor.
• "Can add/change/view Event Types and Categories 2.0 (Beta)" — controls only the admin's link row. Any staff account with an activity permission can already see the link.
• Event category permissions (add_eventcategory, change_eventcategory, delete_eventcategory) — only needed if the provider should be able to create, rename, or delete entire categories. Leave these out for single-category curation.

Good to know

• The read-only lists aren't scoped to the integration. observations.view_source, view_subject, and view_subjectgroup let the account list all sources, subjects, and subject groups site-wide via the API, not just ones related to the provider's integration. view_subject does not include subject locations. Choices work the same way — they're a single site-wide table, so a Choice Editor account can edit choice lists used by any category's forms, not only their own.
• Grant permissions through permission sets, not directly on the user. EarthRanger only resolves these codenames through permission-set membership; a permission added directly to a user record won't take effect.

Verify it worked

Sign in as the provider's account and open the event type editor. You should see:

• The "Event Types and Categories" link in the admin, and the editor opens
• Only their own category (plus any others granted) in the event types list
• They can open, edit, create, and reorder event types in that category
• They can add, edit, and disable choices

And confirm they cannot:

• Open event types belonging to other categories
• Create, rename, or delete event categories
• Manage users, permission sets, or other admin areas