Machine Name element description should allow for cases where machine name uses hyphens

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request → as a guide.

As a bug it will need a test case.

I converted #31 to an MR and added an assertion for the updated machine name element description.

Won’t this require updating machine_name schema now too?

Just reading the proposed solution “check replacement key…” not sure that’s been implemented.

Title made me think that hyphens are valid machine names and is that true? What will that break

prashant.c → made their first commit to this issue’s fork.

For this we only need to replace -with _in the replace_patternand replacekeys of the machine_nameelement.
This will allow lowercase letters, numbers, and underscores, and the "replace" key will replace other special characters with _.

Please review.

Should be a test around that change. Probably can drop the test for the description

Also I’m not sure hyphen is a valid machine character

Will try to add test coverage, if hyphen(-) is used in the machine name, it will get replaced by underscore(_).

The issue summary explicitly says "Shortcut machine names require hyphens." If this is being undone, then justification for that needs to be given and the IS should be updated accordingly. Please ensure that proper research into this change has been performed.

Just reading the proposed solution “check replacement key…” not sure that’s been implemented.

The IS needs to be updated. I forgot to do it. In #22 @alexpott outlined the solution: any element that overrides the replacement pattern should also override the description to describe the change. In #23 he clarified that statement to say that we don't want to get into the business of trying to build a regex parser to do that work automatically.

Thus, the solution to this issue is to have the Shortcut's machine name element override the description and also update the machine name Element's docs to add text saying "if you override the replacement pattern, then you also need to override the description."

Title made me think that hyphens are valid machine names and is that true?

All I know is that the IS says: "Shortcut machine names require hyphens." And I didn't look into why, but currently the element does replace disallowed characters with hyphens. I'm guessing there's no test coverage around it since the last change made by @prashant.c didn't break anything.

I updated the IS and issue title.

For the record, there's no restriction on using hyphens in machine names, other than what's defined in the element's replace_pattern. This is easy enough to test. Just make a Shortcut Set at /admin/config/user-interface/shortcut/add-set that contains spaces or other disallowed characters. The disallowed characters get replaced with hyphens with no problem. Save it and then view it in the config export page. There's no problem when you export the config to files either. It's saved with hyphens no problem.

I reverted @prashant.c's changes because they were out-of-scope. Then I added more assertions that to verify that hyphenated machine names are allowed and valid, but underscores are not.

Thank you, @dcam, maybe I misunderstood the issue, so now hyphens are allowed whereas underscores are not.

I also misunderstood this ticket so apologize @prashant.c and @dcam.

So this is actually pretty straight forward and may not need the test coverage. Lets see what the committers think.

I'd classify this as normal.

Making the title a bit stronger.

Removing credits for redundant manual testing.

Queued fresh pipelines to run the test-only job, since I learned today it expires if the pipeline is more than a week old. (Contributors, you can do this from the "pipelines" local task on the MR page. The link for it is above the diff UI, not the one in the sidebar.)

Test-only results:

There was 1 failure:
1) Drupal\Tests\shortcut\Functional\ShortcutSetsTest::testShortcutSetAdd
Behat\Mink\Exception\ResponseTextException: The text "A unique machine-readable name. Can only contain lowercase letters, numbers, and hyphens." was not found anywhere in the text of the current page.
/builds/issue/drupal-3052479/vendor/behat/mink/src/WebAssert.php:907
/builds/issue/drupal-3052479/vendor/behat/mink/src/WebAssert.php:293
/builds/issue/drupal-3052479/core/tests/Drupal/Tests/WebAssert.php:981
/builds/issue/drupal-3052479/core/modules/shortcut/tests/src/Functional/ShortcutSetsTest.php:58
FAILURES!
Tests: 12, Assertions: 163, Failures: 1.

That's good, but should we also be asserting that the shortcut set was not saved? Generally asserting error messages by itself isn't robust enough. So I just think we need to add one more assertion above this one about the entity being unchanged. Might have to clone it or whatnot.

Thanks!

Removed leading space from title.
Proofread all strings and added one extra comment to the MR.

That's good, but should we also be asserting that the shortcut set was not saved? Generally asserting error messages by itself isn't robust enough.

@xjm that assertion isn't testing for an error message. It's checking for the unique machine name element description. Since the focus of this issue is specifically about that description being incorrect I wrote the assertion to check for the corrected version. But since you asked, I also included assertions to check for whether a hyphenated machine name and another attempt to save an underscored machine were correctly saved. This was because a misunderstanding starting at #37 revealed that there was no test coverage for the hyphenated naming scheme.

I addressed all feedback. Since the only changes were to code comments, one of which was written and suggested by a release manager, I'm going to be bad and self-RTBC this.

Sorry, I'm clueless. I missed something important there.

Ok, so I wasn't entirely stupid. The failing test that @xjm referenced is for the machine name element description. But there is a different assertion further down that checks for an error message. The description and error message have nearly identical text, resulting in the confusion we both had. @xjm was correct to request that an additional assertion be added. However...

So I just think we need to add one more assertion above this one about the entity being unchanged.

There's no entity being changed here. It's an attempt to create a new shortcut set with underscores in the ID. It should be sufficient to check that an attempt to load the set returns NULL, which is what I added.

There's no entity being changed here. It's an attempt to create a new shortcut set with underscores in the ID. It should be sufficient to check that an attempt to load the set returns NULL, which is what I added.

Right, sorry, I was writing as if the shortcut set already existed, but what I should have said (what I was trying to say) is that no changes should be saved for the shortcut set since it was failing validation. And in the end that's what you did. Sorry for misleading review comments and glad you were able to translate what I meant in the end!