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

Afform - Provide default page_route for every form #31834

Closed
wants to merge 1 commit into from

Conversation

colemanw
Copy link
Member

@colemanw colemanw commented Jan 20, 2025

Overview

Ensures every afform is accessible via page route. This allows any afform to be used in a link or popup dialog without requiring the user to configure a route.

Before

Previously if a form did not have a page route it was inaccessible from any URL.

After

Now a default url exists for every form: civicrm/afform/view/{afformName}. This is similar to the way Drupal nodes all have a default url of node/{nid}.

FormBuilder UI updated to show that a custom route is optional, and a form can still be viewed in a page or popup or added to the navigation menu. If blank, the placeholder shows the default route:

image

Previously if a form did not have a page route it was inaccessible from any URL.

Now a default url exists for every form: `civicrm/afform/view/{afformName}`.
This is similar to the way Drupal nodes all have a default url of `node/{nid}`.
Copy link

civibot bot commented Jan 20, 2025

🤖 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...

➡️ Online demo of this PR 🔗

@totten
Copy link
Member

totten commented Jan 21, 2025

Screenshot 2025-01-20 at 6 57 58 PM

Aaah, yeah. We live in a world with different types of forms. From a UX POV, the most common case of "New Form" would be like "New Submission Form", and you almost always want an HTTP route for that. Embeddable things -- like dashlets and subforms -- are valid but probably less common.

Thinking out loud....

  1. Does it impact existing non-HTTP forms? Like, we don't want existing dashlets/subforms to get suddenly published. And in the future, we might want a GUI button for "New Field Block" (or similar) -- where it doesn't have a default route.

    • I think it's OK here, but I should r-run a few arrangements of local/packaged and routed/non-routed...
  2. If the user starts the drafting process on a live/routed document but hasn't looked at settings like "Security" yet... how much risk-exposure is there?

    • I think we're OK here, at least for a first approximation. On a new form, it defaults to RBAC (User-based) security. So if some malicious user discovers a draft (by guessing at URLs with common words), then they don't gain any special privileges.
  3. The patch looks bigger than I expected from the description. And maybe I don't fully grok, but just thinking out loud:

    • In my mind, "provide default route" is a function of the GUI editor.

    • It looks like the patch is going a bit further... and... changing the meaning of the fields. Like:

      Before: server_route is the only way to set the server_route.

      After: If server_route is blank, then it's not routed, unless "Navigation Menu" is enabled, and then a server route is defined by an implicit pattern. (And because this changes the meaning of the fields in the data-model, it has to be applied across multiple files -- client-side and server-side).

    • I don't know if this maybe solves some other problem. But my gut says that (6 months later) we're more likely to regret having conditionality on the meaning of server_route.

  4. It's kind of appealing how the URL/ID works in (say) Google Docs -- when you make a new artifact and share it, the URL includes a random code. This prevents crawling/discovery. (This seems even more useful in afform, since we don't have formal flags for "Draft/Published".) It means you can test with a small group without the risk of being discovered/viewed by others.

Anyway, I'll still do some r-run around that first question. But I encourage to consider (or maybe get some 3rd party feedback) on third/fourth.

@@ -1,5 +1,10 @@
<?xml version="1.0" encoding="iso-8859-1" ?>
<menu>
<item>
<path>civicrm/afform/view</path>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@totten just to clarify your questions about server_route, the heart of the PR is right here, where we add a new generic menu route that handles all afforms. Going to this route and appending the name of a form (e.g. civicrm/afform/view/myCoolForm) will load that form.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aaah, OK. That interpretation is clearer.

Comment on lines +12 to +15
$formName = $pageArgs['afform'] ?? NULL;
if (!$formName && $this->urlPath[0] === 'civicrm' && $this->urlPath[1] === 'afform' && $this->urlPath[2] === 'view') {
$formName = $this->urlPath[3];
}
Copy link
Member Author

@colemanw colemanw Jan 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@totten the other half of the heart of the PR is here, where the afform base page is routed both from the form-specific server_routes, and also from the generic route. This patch adds handling for the generic route (when $pageArgs is empty).

FYI to clarify your question about the navigation menu and conditionality, I think you may have misread that bit. No it's not conditional. The generic route is available for every form.
Effectively that means that if you give your form a server_route, it is now availble in two places.
This is the same as for e.g. drupal nodes, where if you give it a vanity url it is now available a /my-cool-page and it is also still available at /node/123.

The rest of the PR is just updating the GUI to account for the availability of the generic routes.

if (!empty($afform['navigation']) && !empty($afform['server_route'])) {
if (!empty($afform['navigation'])) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@totten maybe this is what you interpreted as being conditional. What's happening here is I'm removing the condition.
Previously a nav menu could only be added for Afforms with a server_route defined. That's no longer the case, since now every afform has a route, so nav menu functionality can be made available unconditionally.

@colemanw
Copy link
Member Author

@totten I take your point about security/privacy. We have no way to unpublish a form, so if a url route is permanently enabled, we get overexposure.

Maybe your assumption that a default route is provided by the gui is the safer path forward... although that too could be problematic if the user doesn't notice the default being filled in for them. But at least it wouldn't expose all previously unexposed forms.

I'm less concerned about forms that shouldn't have a url having one. Afforms that are not meant to be viewed at a page route (blocks, subforms, etc) will be non-functional or nonsensical at the default route, but so what? No one will ever have a reason to go to those urls.

@totten
Copy link
Member

totten commented Jan 21, 2025

...have no way to unpublish a form, so if a url route is permanently enabled, we get overexposure.

Yes, well put.

Afforms that are not meant to be viewed at a page route (blocks, subforms, etc) will be non-functional or nonsensical at the default route, but so what? No one will ever have a reason to go to those urls.

Sort of. I mean, if you're probing a system for weaknesses, then that's exactly the kind of URL you go to. The behavior is undefined. As in: it does "something", but there is no "sensible" thing to do. Whatever arbitrary behavior it has today would quietly change another arbitrary behavior in two months.

I'm not trying to make a hassle, and I don't want to dig in heels against the wildcard path. Like if there's a good reason we need the complexity, then OK. But from where I'm sitting, it seems like a simpler patch (e.g. totten@332bd9f) does the job. Or, maybe with a bit polish, it might be like #31843

@colemanw
Copy link
Member Author

@totten the more I think about it & discuss it, the less I like this PR so I'm going to close it.
The only reason I did 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.

@colemanw colemanw closed this Jan 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants