(dev/core#5606) user_dashboard - Fix upgrade error

[totten]

Overview

This fixes an upgrade error reported in https://lab.civicrm.org/dev/core/-/issues/5606.

The general issue is that the upgrader checks Afform metadata. But this particular metadata file (afsearchUserDashboard.aff.php) has an unusual sort of dynamism that doesn't work in upgrade context. So we move it somewhere that does work.

(ping @colemanw)

Before

Whenever you try to read any metadata bout afsearchUserDashboard, it tries to immediately render a dynamic layout.

After

It only renders the dynamic layout when it needs to (which is not during the upgrade).

Technical Details

To ensure that the code works the same as I before, I dumped some example output before+after. Compare:

cv en user_dashboard
cv ang:html:show afsearchUserDashboard/afsearchUserDashboard.aff.html  > /tmp/before.html

## Apply patch, then...
cv ang:html:show afsearchUserDashboard/afsearchUserDashboard.aff.html  > /tmp/after.html

diff -u /tmp/before.html /tmp/after.html
md5sum /tmp/before.html /tmp/after.html

For me, this gives the same output.

Comments

• With this procedure to reproduce, I see the upgrade working.

• One thing that I'm not sure about is the story of a site-builder who edits afsearchUserDashboard:

  • I don't understand that story before the patch. It seems to me that... once an edit is made... the ability to enable or disable dashlets would break. So my suspicion is that this story just generally isn't expected/supported?
  • The current patch should work the same in that case.
  • But if the admin tries to edit, then this patch works different -- basically, those edits should be ignored/inert. (The hook_alterAngular listener is written to replace the full layout.)

• I think dynamism in *.aff.php is like dynamism in other metadata files (*.ang.php, *.setting.php). It can be done. It's a valid quick-hack to prove a concept. But for long-term maintainability, one looks for something else.

[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 I'm glad to see this fixes the upgrade error. I agree the dynamism feels a bit off, but let's go ahead and merge this first.