AC-2466 - Added ability to retrieve config paths instead of XML paths for use when re-encrypting data

[Skullsneeze]

Description (*)

This PR aims to resolve issue #35061. The issue describes how data is not re-encrypted when a new encryption key is being generated.

I found that the Change controller retrieves all config fields from the XML structure based on the backend_model being set to \Magento\Config\Model\Config\Backend\Encrypted. While this works, the paths which are returned are the full XML paths. There is however an option to define a <config_path> node, which will be used in the core_config_data table to store the configuration value.

Since the Controller checks directly against this table, a lot of paths seem to be "incorrect" and are not retrieved as values to re-encrypt.

In this PR I added a parameter (for backward compatibility) to retrieve the config path, instead of the full XML path.

Related Pull Requests

N/A

Fixed Issues (if relevant)

1. Fixes Encryption key change doesn't re-encrypt any config values using the new key #35061

Manual testing scenarios (*)

1. Store an encrypted value where the XML contains a config path (eg. Stores > Configuration > Sales > Payment Methods > PayPal Express Checkout > API Password
2. Check the value of the encrypted configuration in the database (the first digit indicates the encryption key version). Additionally you can use a tool like Magerun to verify the decrypted value (config:store:get --decrypt paypal/wpp/api_password)
3. Navigate to the encryption configuration page ( System > Manage Encryption Key)
4. Generate a new encryption key (Auto-generate a Key > Yes > Click: Change Encryption Key)
5. After the encryption key has been generated, check if the encryption has been updated in the database. Again, you can use a tool like Magerun to verify the decrypted value (config:store:get --decrypt paypal/wpp/api_password)

Questions or comments

1. If it's safe to do so, I would suggest always returning the config path if it's available, meaning the changes in: \Magento\Config\Model\Config\Structure::_getGroupFieldPathsByAttribute could be simplified to a simple: $field['config_path'] ?? $parentPath . '/' . $field['id'].
2. I've added strict types, but I'm not sure if this is already the standard for core Magento. if not this can be removed.

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• All automated tests passed successfully (all builds are green)

[m2-assistant]

Hi @Skullsneeze. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.

Add the comment under your pull request to deploy test or vanilla Magento instance:

• @magento give me test instance - deploy test instance based on PR changes
• @magento give me 2.4-develop instance - deploy vanilla Magento instance

❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[Skullsneeze]

@magento run all tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please message the #magento-devops slack channel if they don't show in a reasonable amount of time and a representative will look into any issues.

[Skullsneeze]

Will take a look at the failing build. I believe there is a proxy class which is causing the builds to fail

[Skullsneeze]

@magento run all tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please message the #magento-devops slack channel if they don't show in a reasonable amount of time and a representative will look into any issues.

[Den4ik]

@magento run all tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please message the #magento-devops slack channel if they don't show in a reasonable amount of time and a representative will look into any issues.

[Den4ik]

@magento run WebAPI Tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please message the #magento-devops slack channel if they don't show in a reasonable amount of time and a representative will look into any issues.

[Skullsneeze]

@magento run all tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please message the #magento-devops slack channel if they don't show in a reasonable amount of time and a representative will look into any issues.

[Skullsneeze]

Looking at the remaining failed test result I'm coming to the following conclusions:

Unit test:

Error	Findings
The at() matcher has been deprecated. It will be removed in PHPUnit 10. Please refactor your test to not rely on the order in which methods are invoked.	This error is unrelated to the changes made in the PR

Semantic version checker:

Error	Findings
M120 [public] Method return typing changed.	Strict typing was applied and could be reverted. I don't see a need however, as the method always returns an empty array, or the result of an array_merge()

Functional test (B2B, CE, EE):

Error	Findings
Several test with status Failed	All these result appear unrelated to the changes made in this PR
Several test with status Broken	All these result appear unrelated to the changes made in this PR

[Skullsneeze]

@magento run Sample Data Tests CE, Sample Data Tests EE, Sample Data Tests B2B

[magento-automated-testing]

Failed to run the builds. Please try to re-run them later.

[Den4ik]

@magento run all tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please message the #magento-devops slack channel if they don't show in a reasonable amount of time and a representative will look into any issues.