Observations and Decision on Admin Product Editing

What Was Found Out

The new HappyBaby public side operates separately from MODX, but MODX remains the working backend and existing administrative environment.

For the quick edit button, it makes no sense to build a second admin panel in the new frontend. At the first stage, it is more correct to use the existing MODX Manager and provide the administrator with a quick jump to editing the current product.

The main technical question turned out to be not the button itself, but determining administrative authorization on the new frontend.

In fact, the necessary MODX cookie already exists and is sent by the browser in requests from the new frontend. This means that an additional authorization system or synchronization of the MODX user with the haih-agent database is not needed at this time.

Adopted Direction

Add a separate GraphQL query that returns the current MODX user based on the existing MODX session/cookie.

MODX remains the single source of truth for this authorization. The MODX user at this stage:

• is not migrated to the haih-agent database;
• is not synchronized with the regular User model;
• does not receive a separate second session;
• is simply returned as an external current MODX user if the native MODX session is valid.

If GraphQL returns the current MODX user, the frontend considers the visitor to be an administrative user and displays the admin toolbar.

UI

It is better not to mix administrative action with customer buttons on the product card. The preferred option is a separate reusable admin toolbar / admin action layer, visible only when the current MODX user is present.

First toolbar action:

• Edit product → open the corresponding resource in MODX Manager.

Such a toolbar can later be reused for other administrative actions and page types without creating a new admin panel.

What is Needed for Implementation

1. Add a GraphQL query for the current MODX user via native session/cookie.
2. Return only the necessary frontend user data; do not embed them into the local User model.
3. Request the current MODX user on the frontend.
4. If the user is present, display the admin toolbar.
5. Generate a link to edit the corresponding MODX resource for the product card.
6. Ensure that the original MODX resource ID is available for the product; if not, add it to the product data.

Why This Option Was Chosen

It uses the already existing authorization and administrative system, does not duplicate MODX ACL, and does not create an additional auth loop for the sake of a single function. At the same time, the frontend receives the minimum necessary signal for the admin UI and remains loosely coupled with the internal MODX user model.