Form Builder - Assign a default route to new "Submission Forms" and "Search Forms"

[totten]

Overview

Compare with #31834.

Before

• When you make a "New Submission Form" or "New Search Form" (or "Clone" an existing one), the form starts out unpublished. You can edit the new form, but you cannot view it. (It has no URL.) You have to take steps to make-up a URL.

After

• When you make a "New Submission Form" or "New Search Form" (or "Clone" an existing one), it starts out with a real URL. Specifically:

  Type	URL
  "Submission Form"	civicrm/form/XXXX-XXXX-XXXX
  "Search Form"	civicrm/search/XXXX-XXXX-XXXX

  The value is random but completely editable.

Comments

• When you first make a new screen, you may be going back/forth in your own mind about what the screen should do. In effect, you are drafting the document. As a draft, you don't want random people to guess+access. But you do want it to be sufficiently live that you can use it (and maybe share with a colleague). The random ID is a very simple way to make it live without making it de facto public.

• This patch does not affect "Field Block" forms. For that scenario, you still start out unpublished. And unpublished items are not web-addressable.

• This patch doesn't require any changes to data-model or routing mechanics.

[civibot]

🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷

Introduction for new contributors...

• If this is your first PR, an admin will greenlight automated testing with the command ok to test or add to whitelist.
• A series of tests will automatically run. You can see the results at the bottom of this page (if there are any problems, it will include a link to see what went wrong).
• A demo site will be built where anyone can try out a version of CiviCRM that includes your changes.
• If this process needs to be repeated, an admin will issue the command test this please to rerun tests and build a new demo site.
• Before this PR can be merged, it needs to be reviewed. Please keep in mind that reviewers are volunteers, and their response time can vary from a few hours to a few weeks depending on their availability and their knowledge of this particular part of CiviCRM.
• A great way to speed up this process is to "trade reviews" with someone - find an open PR that you feel able to review, and leave a comment like "I'm reviewing this now, could you please review mine?" (include a link to yours). You don't have to wait for a response to get started (and you don't have to stop at one!) the more you review, the faster this process goes for everyone 😄
• To ensure that you are credited properly in the final release notes, please add yourself to contributor-key.yml
• For more information about contributing, see CONTRIBUTING.md.

Quick links for reviewers...

• ➡️ PR Demo site (can be rebuilt with the command test this please).
• 📖 Review standards
• 🗒️ Review template (brief or verbose)

➡️ Online demo of this PR 🔗

[colemanw]

@totten the more I think about it & discuss it, the less I like my original PR so I've closed it.
The only reason I raised this was to avoid making the user enter a url_route when they chose to place an afform in the contact summary actions menu.

But really it's not that much hassle and so for now I'm just going to make it required: 8996df2

That takes the pressure off this & we can slow down and think about whether we really want it.

[ufundo]

if I've understood this correctly, this will preserve the existing route when you clone a form? what happens if you (try to) save two forms with the same route?

[totten]

In isolation, that would be true. But d249a99 has (had) two parts:

1. In the PHP side, loadAdminData prepares the definition of the new form. The PHP side assigns a new server_route (civicrm/form/XXXX-XXXX-XXXX) for the clone.
2. On the JS side, after it retrieves a definition, it needs to present it. This JS line blocked it from presenting the new route.
   • Before: PHP loadAdminData was feeding duplicate routes, so JS needed to discard those
   • After: PHP loadAdminData is feeding usable routes, so JS can keep them.

To your 2nd question, I'm not sure what happens if you make a duplicate in general. But I'm sure that the risk is much lower here than with the status-quo/chosen paths.

(My math is rusty, but it looks like 62-bits of entropy in the formula. For comparison, the mix of English words that a user would brainstorm for mnemonic URLs is... a ballpark of... 10-20 bits, generously speaking?)

---

Aside, after re-reading that commit, it looks like I had some rose-colored glasses and created a different bug (trampling the route on normal edits). Updating the clone operation isn't quite as elegant as updating "New Form" operation.

Posted updated flavors -- eg chocola PHP (c0854e8) or JS (totten@c6c7d85).