Task: Unify request interfaces

Unify request interfaces

03.09.2026Kilfor.ru

Currently, visitor requests and entry/exit requests are separate entities (due to specific customer business requirements and separate allowed/disallowed permissions). Historically, different pages and forms were used to work with these different request types. We certainly won't change the business logic and architecture, but we can and should unify the interfaces. We will make the creation form universal by simply adding a switch for "Material" or "Visitor only" (just to correctly check if the form is filled out, so that a user doesn't create a visitor-only request while forgetting to specify what they want to bring in or take out, without the form highlighting it). For the output, we can use a single interface utilizing union objects in GraphQL.

Ворклоги

Unified pass requests in GraphQL and the new user account

Historically, the Kilfor system had three different types of pass requests:

  • visitor requests;
  • material entry/exit requests;
  • vehicle entry requests.

These types use different database table sets, and in some scenarios, the set of fields also differs. I intentionally did not change the database structure or the existing business logic so as not to affect the stable legacy backend.

The unification was done at the GraphQL API and frontend level. A union type and unified resolvers were added to GraphQL, allowing different pass types to be retrieved through a common interface. As a result, requests from different sources are now read and displayed as a single list regardless of which physical tables they are stored in.

On the frontend, a unified request creation form with a pass type switcher was implemented. The user works with a single interface, while the necessary set of fields and form logic adapt to the selected scenario: visitor, material entry/exit, or vehicle.

This removed the historical fragmentation of the interface into several separate pages and forms while preserving the existing data structure and access permissions. The result is a unified UX for pass requests without risky data migration and rewriting the MODX backend.