Resource and Support content types can not update alias

[swirtSJW]

Notes from November 2023 (Jill):

Today, I was able to login as content admin (on Staging) and check the "Generate alias" box and save the update, so re: #2 in ticket body, that reported error validation piece of this doesn't repro anymore. I don't have a means to confirm the FE publish went through, since I was on Staging.

In general I do think we'll need to step through this report again and confirm if prod today behaves the same way or not. Could timebox this for that if we wanted to.

Description

1. On a published R&S node: you cannot change the alias of a published node.
   If you check the box to make it use the alias pattern, it does not make it through the publishing pipeline.
   

2. As content-admin or admin: try to force a change in the alias field is validated / errors and will not save.
   

3. Bulk Operations: if you use a bulk operation to move a node or many nodes from unpublished to published, aliases do not appear to get updated.

This seems to be a collision of the following two PR's that were merged in Nov 2020:

• VACMS-3197 aliases part b #3259
• VACMS 2912: Force editors to save first as draft or in review, then publish on the proofing pages. #3207

Workaround: For now the only workaround is to use /admin/config/search/path

Repro steps

ACs

• Test in a tugboat to attempt to reproduce.
• If not reproducible, then close ticket.
• If reproducible, we'll determine as a team what to do (use this ticket or create a new one)

[swirtSJW]

This was put up as a quick undo, but decided against.
#3408

https://dsva.slack.com/archives/CT4GZBM8F/p1604677259307200

[jilladams]

Today, I was able to login as content admin (on Staging) and check the "Generate alias" box and save the update, so re: #2 in ticket body, that reported error validation piece of this doesn't repro anymore. I don't have a means to confirm the FE publish went through, since I was on Staging.

In general I do think we'll need to step through this report again and confirm if prod today behaves the same way or not. Could timebox this for that if we wanted to.

[dsasser]

I tested this out on Tugboat logged in as a Content Admin (not a Drupal administrator) and was not able to reproduce the issue. See below:

Per ACs, closing as a no-op.