Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bin/magento config:set expects config path to match display path #27678

Closed
navarr opened this issue Apr 9, 2020 · 6 comments · Fixed by #31621
Closed

bin/magento config:set expects config path to match display path #27678

navarr opened this issue Apr 9, 2020 · 6 comments · Fixed by #31621
Assignees
Labels
Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Issue: ready for confirmation Priority: P2 A defect with this priority could have functionality issues which are not to expectations. Progress: done Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch Severity: S2 Major restrictions or short-term circumventions are required until a fix is available. Triage: Dev.Experience Issue related to Developer Experience and needs help with Triage to Confirm or Reject it

Comments

@navarr
Copy link
Member

navarr commented Apr 9, 2020

Summary

We're updating our configuration to be more user friendly and this involves creating new categories to move configuration around. While doing this, we want to maintain backwards compatibility and so have set config_paths for most of our settings.

An example would be tax/vertex_settings/trustedId is now in system.xml as tax/vertex/connection/trusted_id - but has config_path set to tax/vertex_settings/trustedId. This field has a backend model to encrypt the data in it.

The problem being experienced is that the data is being entered into the database unencrypted - leading it to be considered encrypted and then the code receiving junk data.

This is occurring because the config:set command pulls apart the path and sends it as if that were the path being sent by the form.

So when we enter Magento\Config\Model\Config our $groupPath is tax/vertex_settings and our $groupData is ['fields' => ['trustedId' => ['value' => '<value>']]].

It SHOULD be:

  • groupPath = tax/vertex/connection
  • groupData = ['fields' => ['trusted_id' => ['value' => '<value>']]]

One might then try to run config:set tax/vertex/connection/trusted_id <value> however this returns that the config does not exist

Manual testing scenarios (*)

  1. Create sample module with system.xml like this
    <system>
        <section id="sales">
            <group id="general">
                <field id="keyid" type="text" sortOrder="100" showInDefault="1" showInWebsite="1" showInStore="0">
                    <label>Key Id</label>
                </field>
            </group>
        </section>
    </system>
  1. Set some value via CLI
    bin/magento config:set sales/general/keyid 1
    We can see Value was saved. as expected.
  2. Add some config_path to system.xml like this
    <system>
        <section id="sales">
            <group id="general">
                <field id="keyid" type="text" sortOrder="100" showInDefault="1" showInWebsite="1" showInStore="0">
                    <label>Key Id</label>
                    <config_path>custom_path/keyid</config_path>
                </field>
            </group>
        </section>
    </system>
  1. Clear cache config
  2. Try to set some value via CLI again
    bin/magento config:set sales/general/keyid 777

Actual Result:

The "sales/general/keyid" path doesn't exist. Verify and try again.

Expected Result:

Value was saved.

Proposed Solution

Update Magento\Config\Model\Config\PathValidator to check if an element exists by the path presented to it, and if it has a config path, use that instead for validation.

Inserting into the top of the validate command:

        $element = $this->structure->getElementByConfigPath($path);
        if ($element->getConfigPath()) {
            $path = $element->getConfigPath();
        }

This is my proposed solution over trying to determine the display path via the config path, as more than one display path can have the same config path. This change would then allow config:set tax/vertex/connection/trusted_id (and other "display paths")

@navarr navarr added the Triage: Dev.Experience Issue related to Developer Experience and needs help with Triage to Confirm or Reject it label Apr 9, 2020
@m2-assistant
Copy link

m2-assistant bot commented Apr 9, 2020

Hi @navarr. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

  • Summary of the issue
  • Information on your environment
  • Steps to reproduce
  • Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

@navarr do you confirm that you were able to reproduce the issue on vanilla Magento instance following steps to reproduce?

  • yes
  • no

@magento-engcom-team magento-engcom-team added the Issue: Format is not valid Gate 1 Failed. Automatic verification of issue format is failed label Apr 9, 2020
@igrybkov
Copy link
Contributor

igrybkov commented Apr 9, 2020

I could also add that there's another scenario that's not covered now.
We have a configuration value but don't want it to be changed through UI (we're fine to change it through CLI or env.php as we doing now). So it's defined only in config.xml, but not in system.xml. Magento is fine to read this value and it could be redefined in env.php, but we can't modify it through config:set.

@navarr
Copy link
Member Author

navarr commented Apr 9, 2020

@igrybkov Good call out. Both use cases would be fixed if config.xml was more definitive than system.xml

@ghost ghost added Issue: ready for confirmation and removed Issue: Format is not valid Gate 1 Failed. Automatic verification of issue format is failed labels Oct 21, 2020
@stale
Copy link

stale bot commented Jan 5, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 14 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale issue label Jan 5, 2021
@navarr
Copy link
Member Author

navarr commented Jan 5, 2021

bump

@stale stale bot removed the stale issue label Jan 5, 2021
@gabrieldagama gabrieldagama added Priority: P2 A defect with this priority could have functionality issues which are not to expectations. Severity: S2 Major restrictions or short-term circumventions are required until a fix is available. labels Jan 12, 2021
@engcom-Alfa engcom-Alfa added Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed labels Jan 26, 2021
@magento-engcom-team
Copy link
Contributor

✅ Confirmed by @engcom-Alfa
Thank you for verifying the issue. Based on the provided information internal tickets MC-40630 were created

Issue Available: @engcom-Alfa, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Issue: ready for confirmation Priority: P2 A defect with this priority could have functionality issues which are not to expectations. Progress: done Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch Severity: S2 Major restrictions or short-term circumventions are required until a fix is available. Triage: Dev.Experience Issue related to Developer Experience and needs help with Triage to Confirm or Reject it
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

6 participants