Download the PHP package coresh/module-customer-attribute without Composer

Coresh_CustomerAttribute Documentation

Overview

The Coresh_CustomerAttribute module adds a stable customer uuid attribute to Magento 2 / Adobe Commerce.

The module automatically assigns UUIDs to existing and new customers, enforces UUID uniqueness, displays UUIDs in the Admin customer grid, prevents manual UUID changes, and exposes UUID through GraphQL only for authenticated customers.

Compatibility

• Magento Open Source 2.4.7+
• Adobe Commerce 2.4.7+
• Magento 2.4.8 / 2.4.9 compatible
• PHP 8.2+
• Composer-installable Magento 2 module

Installation

1. Install the module

Using Composer:

If installing manually, place the module in:

2. Enable the module

3. Run Magento setup

4. Verify module status

Expected result:

Database Verification

Verify the UUID column on customer_entity

Expected result:

Verify UUID values for customers

Expected result: each customer should have a UUID value.

Verify UUID uniqueness

Expected result:

Verify UUID in the customer grid index

Expected result:

Then verify values:

Admin Verification

Open Magento Admin:

Verify:

If the UUID column is not visible immediately, run:

GraphQL API Access

The module extends the existing GraphQL Customer object with the uuid field.

UUID is available only through authenticated customer GraphQL requests.

GraphQL query

GraphQL Testing with curl

Set test variables:

1. Verify guest access is rejected

Expected result: the request should be rejected with an authorization error.

The response must not expose uuid.

2. Generate customer token

Expected result: a customer bearer token is returned.

3. Verify authenticated UUID access

Expected result:

4. Verify UUID format

Expected format:

Example:

Testing Procedures

1. PHP syntax check

Expected result:

2. Composer validation

3. Magento dependency injection compilation

Expected result: compilation completes without errors.

4. Magento setup and index verification

Expected result: setup and customer grid reindex complete successfully.

5. Unit tests

Expected result:

6. Magento Coding Standard

If Magento Coding Standard is installed:

If the Magento test ruleset is available:

7. Integration tests

Integration tests require a configured Magento integration testing environment.

Check that the integration test configuration exists:

Run integration tests:

Functional Acceptance Checklist

Rollback Notes

To disable the module:

The module adds persistent database schema changes, including the customer_entity.uuid column. Removing database columns should be handled carefully and only after confirming that no external integrations depend on UUID values.

Recommended safe rollback approach:

Architecture

It automatically:

• assigns unique UUIDs to existing customers;
• assigns UUIDs to new customers;
• prevents manual UUID changes;
• displays UUIDs in the Admin customer grid;
• exposes UUIDs through GraphQL only for authenticated customers.

Its main purpose is to give each customer a stable, unique, secure external identifier without exposing the internal customer_id.

Installation

During bin/magento setup:upgrade, the module creates the customer UUID attribute metadata, updates the customer grid configuration, and assigns UUIDs to existing customer records.

Module Overview

The architecture uses both Data Patches and a Plugin because they solve two separate Magento lifecycle problems.

A Data Patch handles installation and upgrade-time work. It is the right place to create the customer attribute metadata, configure the attribute for the Admin customer grid, and backfill UUIDs for existing customer records during bin/magento setup:upgrade.

A Plugin handles runtime behavior. It is responsible for assigning a UUID when a new customer is saved and protecting an existing UUID from being changed through Admin, REST API, GraphQL, imports, or custom code.

These two mechanisms do not replace each other.

Why Data Patches Are Used

The assessment requires UUIDs to be assigned to existing customers when the module is installed. That is installation-time data work, so a Data Patch is the correct Magento mechanism.

db_schema.xml can create the physical database column and unique index:

However, db_schema.xml cannot perform business/data operations such as:

That is why the module uses:

Using old InstallData, UpgradeData, InstallSchema, or UpgradeSchema scripts would be less suitable for a Magento 2.4.7+ implementation. Declarative schema and patches are the modern, production-ready approach.

Why a Plugin Is Used

The Plugin is used because UUID assignment and UUID immutability must be enforced every time a customer is saved.

Customer records can be created or updated through multiple entry points:

The Plugin enforces the rule at the save layer:

This is stronger than relying only on the Admin UI.

Hiding or disabling the UUID field in Admin is not enough because the value could still be changed through direct POST requests, API calls, imports, or custom code. The save layer must protect the UUID.

Can the Module Be Implemented Without Data Patches?

Technically, yes, but it would be weaker for this assessment.

One alternative is a CLI command:

That can be useful for very large production databases because it gives more control and can show progress.

However, by itself, a CLI command does not satisfy the requirement that existing customers receive UUIDs during module installation. Someone may forget to run it, and customers may temporarily have empty UUID values.

A stronger enterprise version could include both:

A cron-based or lazy backfill would be even weaker because UUIDs would not be available immediately after installation.

Can the Module Be Implemented Without a Plugin?

Yes, but another reliable runtime mechanism would still be required.

Possible alternatives include:

An observer can work, but it is less explicit than a CustomerRepository plugin and can become hidden business logic if not designed carefully.

A backend model can also work, but in this architecture the UUID is stored as a static column on customer_entity, not as a normal EAV varchar value. Immutability and collision retry handling are clearer in a dedicated service plus plugin.

A DI preference would be a poor choice because it is more invasive, creates a higher conflict risk with other modules, and is harder to maintain during Magento upgrades.

A database trigger would also be a poor Magento solution because it hides business logic outside the application layer, is harder to test, and is less suitable for Adobe Commerce Cloud-style deployments.

Practical Conclusion

For this assessment, the best implementation is:

The Data Patch prepares the system during installation:

The Plugin protects runtime behavior:

This separation is important:

The most production-ready architecture is therefore:

This design satisfies the assessment requirements while keeping the module upgrade-safe, testable, and aligned with Magento extension architecture.

Check metadata:

Check source of truth:

Check Grid:

GraphQL query Guest request:

GraphQL query Guest request result:

Get Customer Token:

Authenticated request:

Authenticated request result:

Check UUID format request:

Check UUID format request result: