Event portal – authentication, scope and endpoints
How the key-based front portal works: resolving the user by API key, visibility for the super admin and other users, and the rules of the AJAX endpoints.
Overview
A separate page excluded from search engines (noindex) with the user's own or assigned events, grouped company → topic → active/completed. Access: the ?key= parameter (a key of the user_api_key table); AJAX calls send the key in the POST field key.
Visibility
- Super admin (group 1): sees everything and can filter by user and company.
- Other users: by content scope (
getAllowedCompanyIds,getAllowedTopicIds,getAllowedEventIds,getAllowedUserIds), and only events they are involved in (responsible, creator, assignee, assigner, watcher). - The page shows the company list (portal and NAV companies), users and labels.
Data model
Table names carry the installation's own prefix in the database.
Tables read: event, event_description, event_user, topic, label, company, company_object, permission_scope, user_feature, nav.
Endpoints
| Endpoint | Behaviour |
|---|---|
event/event | the portal page |
event/event.list | reloads the grouped list with filters; sub-grouping by topic, label or user |
event/event.topics | active topics of a company; returns data to super admins only, error:auth for a bad key |
event/event.add | new event; super admin only; company and title required, the topic must belong to the company |
event/event.complete | complete or reopen an own or assigned event, or as super admin |
Permissions
The portal checks no function permission (the event/event::list key is not classified in the seed); access comes from the key and the content scope.