Add customer-facing order comments

Interface review.

Regarding the new checkout pane (customer-checkout-pane-4.png):

1. Per #2908196: Add ability to add an order comment #100 from @rszrama: The new checkout pane should be disabled by default. Most sites don't need random order comments on checkout, and keeping it disabled by default means we don't have to worry about module updates suddenly changing checkout forms.
2. Per #2908196: Add ability to add an order comment #100 from @rszrama: If the checkout pane just has a textarea in it, I don't see why its wrapper element should be a fieldset. Can we not just make this a container div?
3. The fieldset uses "Order Comments". It should be "Order comments". However, it makes sense to instead remove the fieldset entirely and just use "Comments". None of the other form elements on this page are preceded with "Order" ("Order shipping address", etc.) so adding the term "Order" is a bit weird.

Regarding the admin interface (order-adminterface-4.png):

1. We use a lot of different strings for the same thing. When a customer puts in a checkout comment, it's shown as "From customer" in the admin UI, but "To admin" in the customer UI. Similarly, when an admin leaves a message to customer, in the admin UI it shows as "To customer" and "To customer, and emailed", but in the user UI, it shows as "From admin". I don't think the word "admin" should ever be shown to the end-user. I would suggest the following revisions:
   • "Admin comment" -> "Admin-only comment"
   • "To admin" -> "Comment from customer"
   • "From admin" -> "Comment to customer"
   • "To customer" -> "Comment to customer"
   • "To customer, and emailed" -> "Emailed comment to customer"

Some other hiccups:

1. A customer's checkout comments are not shown in the emailed receipt. Since the receipt primarily reproduces all the other information gathered from the customer during checkout, the comments should be there too.
2. There are some failed tests that are fixable.
3. In my opinion, we shouldn't be creating a new template for customer comments (commerce-log-customer-comment.html.twig). We should instead a) add order comments to the default commerce order receipt, b) re-send the receipt whenever an emailed customer comment occurs. As it stands now, if I have ordered ten times from your store, and you email me an order comment, I have no idea what the hell you're talking about (see emailed-comment-4.png), and I'd have to go through my own archives (or the website) to recall what order, and what order items, you're emailing about. This makes the email nearly useless. By instead remailing the entire receipt, with the new comments added, everything is contextualized in that single email, and the customer doesn't need to do anything extra to understand what's going on.

And, finally, to @rszrama:

I really don't understand the whole implementation of actually adding comments and comment forms to orders. I expected to see at least an "extra field" I could move around / disable, but nope ... there's no way to hide the comments feature once this patch is enabled. That's a major dealbreaker. Furthermore, this is only exposed via a default Twig template - what if a theme has provided its own? And why not use Views to create the table of comments shown? This smells like it was basically one site's very specific implementation.

I agree that this patch currently merges two different functionalities: the ability for admins to add comments to an order that a customer sees ("here's your shipping number!", "this has been delayed!", "your preorder has been canceled!", "I refunded your shipping. Thanks!", etc.), and the ability for customers to add data for administrators (for clarity, I'll call these "checkout comments").

I need both in my sites. I half-agree that "checkout comments" COULD be implemented (more flexibly) by a custom field. For example, if I'm selling school books and I need to know what school you go to, I'd add a "School" custom field, absolutely. And, sure, I suppose I could add a generic "Checkout comments" field too, but now we're splitting a single mentality ("order comments") into two separate implementations (the log-based "admin comments" and "customer-facing comments", and then a field-based "checkout comments").

For me, the "compromise" is what you've already suggested: the default "Order comments" checkout pane (provided by this patch) should be disabled by default. This will then allow the user to choose the merged all-in-a-log functionality for generic comments, while still allowing them to create custom-order-fields ("School name:") for more controlled pieces of operable data.

My suggestion above:

In my opinion, we shouldn't be creating a new template for customer comments (commerce-log-customer-comment.html.twig). We should instead a) add order comments to the default commerce order receipt, b) re-send the receipt whenever an emailed customer comment occurs. As it stands now, if I have ordered ten times from your store, and you email me an order comment, I have no idea what the hell you're talking about (see emailed-comment-4.png), and I'd have to go through my own archives (or the website) to recall what order, and what order items, you're emailing about. This makes the email nearly useless. By instead remailing the entire receipt, with the new comments added, everything is contextualized in that single email, and the customer doesn't need to do anything extra to understand what's going on.

I'm thinking we can expand on this to support both approaches.

What would be nice for the most flexibility is some way for the themer/site owner to decide if they want the entire order receipt (i.e., what the suggested defaults above are) or if they only want to send comments (i.e., what patch #2 does with emailed-comment-4.png does). My thought here is that whenever an admin chooses to email the customer with an order comment, a new variable is added to the order receipt template called "is_emailed_comment" (or something). This would then allow a themer/site owner to customize their own commerce receipt template to NOT send the non-comment parts of the commerce receipt, something like:

if (is_emailed_comment != 1) {
  render billing address
  render shipping address
  render order items
  render other crap, etc.
}

render order comments

This allows Commerce to support both approaches: full order receipts with comments (i.e. what I think the defaults should be) and "only comments emailed" (i.e., what patch #2 does with emailed-comment-4.png does). But it'd do it all with the existing commerce receipt template, not a new template (like patch #2 does).

Patch 6 (P6) makes some substantial changes to the original patch 2 (P2).

• P2 largely ignored the work to add admin-only comments from @mglaman. The revised P6 integrates with what @mglaman started.
• P2 emailed ONLY the order comment, without any context of the order that was being commented on. In P6, we instead piggy-back off Commerce's existing commerce-order-receipt.html.twig for the email, which now supports showing order comments if they exist. A new twig file has been added called commerce-log-order-comments.html.twig which, by default, is just a copy of that existing order receipt. With this new twig file, it's possible to move your comments to the top of the email or to reproduce the behavior of P2 (by wiping out everything else and using only the first array item of the order_comments variable).

To push back on a @rszrama suggestion: If the checkout pane just has a textarea in it, I don't see why its wrapper element should be a fieldset. Can we not just make this a container div? That's been implemented in this patch (customer-checkout-pane-6.png), and I don't like it. Primarily, every other place that a comment form item appears, they look "better" in a fieldset. On customer-checkout-pane-review-6.png, it looks "better" because all the other data is in a fieldset, on order-adminterface-6.png a fieldset is used for the comment because we've got radios, etc. I'm thinking that we should continue to use a fieldset, named "Comments", but leave the textfield unlabeled (similar to order-adminterface-6.png).

For those using P2 in prod, there are potentially breaking changes:

• P6 disables the checkout pane by default.
• P6 renames the log templates to match @mglaman's work: P2 order_comment_admin to P6 commerce_order_admin_comment, P2 order_comment_to_customer to P6 commerce_order_to_customer_comment, P2 order_comment_from_customer to P6 commerce_order_from_customer_comment.
• P2 renames the permissions to match @mglaman's work. The labeling remains the same, but the internal IDs have changed: P2 "add comments to own order" to P6 "add commerce_log commerce_order customer comment".
• The email theme changes mentioned above. commerce-log-customer-comment.html.twig no longer exists and you'd want to migrate any changes to commerce-log-order-comments.html.twig instead.
• P6 renames the event names to commerce_order.comment.admin, commerce_order.comment.from_customer, and commerce_order.comment.to_customer.

#9 works great - badly needed missing feature. I had to install manually - and I am guessing it will soon be committed to Commerce Core

It is disabled by default

Enable after patching at /admin/commerce/config/checkout-flows/manage/default?destination=/admin/commerce/config/checkout-flows

a.k.a /admin/commerce/config/checkout-flows

Thanks for the initiative and creating a new issue.
The new patch does not apply to Commerce 2.30 because commerce_log.install File was extended.
Attached an updated patch.

Reminder ping for review.

We'll try to review this while in Prague.

Haven't really had time to do a proper review, but the first thing I'm noticing is the checkout pane defined, which should be defined by the commerce_log module rather than defining it from commerce_checkout and have all bunch of checks to ensure commerce_log is enabled.

Also what's done from the OrderReceiptMail could be done via a hook_preprocess_HOOK() implemented by commerce_log, so once again we don't have to check if commerce_log is enabled etc.

Is there a reason for the unrelated test changes too?

Will this patch has a chance to get merged? Or should I continue looking for other method?

Thanks,

This needs a re-roll.

Ok, here is a re-roll.

Sorry, I forgot to add the new files.

Tested #24 with latest dev and works.

Thanks,

Hi,

I patched with https://www.drupal.org/project/commerce/issues/3267366 and https://www.drupal.org/project/commerce/issues/2908196 this issue and merged both of it.

The #25 patch contains Comment form in user order page for the user along with permissions + comment form for admin with radio buttons and sending email functionality.

It would be great if anyone can test it please?

Thanks !!

I think that a possibility to add customer-facing order comments is an important feature, so +1 from me and hopefully we will see this in Drupal Commerce soon. As it was mentioned in the referenced issue (#3166853: How to Add Order Comment and also Allow to notify customer via email?), each other eshop system has such comments (magento, ubercart, prestashop, opencart).

I've tested patch from #27.
It works.
But I've noticed one bug:
When add comment and go to review page,
on review page click on Edit near the Comments section
then the page with previous checkout step is opened and the Comment input field is empty.
Adding new comment in this case and submitting checkout step form again will save the comment as new log.
So there are two comment logs.
I haven't time to look into code and check if it's possible to load already created comment log yet.
Maybe it should be fixed?

I've fixed the bug from the previous comment.

Added one more small fix to render a customer comment on the order review page with new lines (if there any in the comment) and not '
' instead.

Thanks for working on this. I have quickly checked the patch and writing a few points.

1. I think there are some unrelated changes, or at least not explained:

+++ b/modules/payment/tests/src/Functional/DefaultPaymentAdminTest.php
@@ -132,7 +132,7 @@ class DefaultPaymentAdminTest extends CommerceBrowserTestBase {
       [
         'absolute' => TRUE,
       ],
-    )->toString();
+    )->getInternalPath();
   }

+++ b/modules/order/tests/src/FunctionalJavascript/OrderAdminTest.php
@@ -424,7 +424,7 @@ class OrderAdminTest extends OrderWebDriverTestBase { 
-    $this->drupalGet($order->toUrl()->toString());
+    $this->drupalGet($order->toUrl());
 
@@ -462,14 +462,14 @@ class OrderAdminTest extends OrderWebDriverTestBase {
-    $this->drupalGet($order->toUrl()->toString());
+    $this->drupalGet($order->toUrl());
 
     // Logout and check that anonymous users cannot see the order admin screen.
     $this->drupalLogout();
-    $this->drupalGet($order->toUrl()->toString());
+    $this->drupalGet($order->toUrl());
   }

+++ b/modules/order/src/Mail/OrderReceiptMail.php
@@ -30,7 +31,7 @@ class OrderReceiptMail implements OrderReceiptMailInterface {
-  public function send(OrderInterface $order, $to = NULL, $bcc = NULL, bool $resend = FALSE) {
+  public function send(OrderInterface $order, $to = NULL, $bcc = NULL, bool $resend = FALSE): bool {

+++ b/modules/order/commerce_order.module
@@ -181,8 +182,8 @@ function template_preprocess_commerce_order(array &$variables) {
-    $profile_view_bulder = \Drupal::entityTypeManager()->getViewBuilder('profile');
-    $variables['order']['billing_information'] = $profile_view_bulder->view($billing_profile, $view_mode);
+    $profile_view_builder = \Drupal::entityTypeManager()->getViewBuilder('profile');
+    $variables['order']['billing_information'] = $profile_view_builder->view($billing_profile, $view_mode);

2. Regarding the templates - I think it would be a little weird to display it this way. As far as I understand, we can have only one comment of type "From customer". Maybe it should be out of foreach to not cause a confusion. Then we should have a foreach just for "To customer" comments and there would be no need to write "Comment to customer" for each row. This is the related code:

+++ b/modules/order/templates/commerce-order-receipt.html.twig
@@ -133,6 +134,44 @@
+                    {% for comment in order_comments %}
+                      <tr>
+                        {% if comment.type == 'commerce_order.comment.to_customer' %}
+                          <td style="border: 1px solid #dee2e6; padding: 0.75rem; vertical-align: top;">{{ comment.date|date("D, m/d/Y - H:i") }}</td>
+                          <td style="border: 1px solid #dee2e6; padding: 0.75rem; vertical-align: top;"><strong>Comment to customer:</strong> <br />{{ comment.comment|raw }}</td>
+                        {% elseif comment.type == 'commerce_order.comment.from_customer' %}
+                          <td style="border: 1px solid #dee2e6; padding: 0.75rem; vertical-align: top;">{{ comment.date|date("D, m/d/Y - H:i") }}</td>
+                          <td style="border: 1px solid #dee2e6; padding: 0.75rem; vertical-align: top;"><strong>Comment from customer:</strong> <br />{{ comment.comment|raw }}</td>
+                        {% endif %}
+                      </tr>
+                    {% endfor %}

+++ b/modules/order/templates/commerce-order--user.html.twig
@@ -33,6 +34,34 @@
+            {% for comment in order_comments %}
+              <tr style="border-bottom: 0.0625rem solid #d3d4d9; color: #232429; background: #fff;">
+                {% if comment.type == 'commerce_order.comment.to_customer' %}
+                  <td style="border: 1px solid #dee2e6; padding: 0.75rem; vertical-align: top;">{{ comment.date|date("D, m/d/Y - H:i")}}</td>
+                  <td style="border: 1px solid #dee2e6; padding: 0.75rem; vertical-align: top;"><strong>Comment to customer:</strong> <br />{{ comment.comment|raw }}</td>
+                {% elseif comment.type == 'commerce_order.comment.from_customer' %}
+                  <td style="border: 1px solid #dee2e6; padding: 0.75rem; vertical-align: top;">{{ comment.date|date("D, m/d/Y - H:i") }}</td>
+                  <td style="border: 1px solid #dee2e6; padding: 0.75rem; vertical-align: top;"><strong>Comment from customer:</strong> <br />{{ comment.comment|raw }}</td>
+                {% endif %}
+              </tr>
+            {% endfor %}

3. Why are we changing the comment output from {{ comment }} to {{ comment|raw }} (and even for the existing admin comments)? Personally I think that comments should be only plaintext and I do not see a reason for this change. It can probably open some vulnerabilities if not handled correctly.

4. As this patch is pretty large, I think it would be great if we can move it to MR instead, so that reviews/comments/progress is easier and more transparent.

Added small fix for the cases if the customer comment contains apostrophes and when we go back to edit the comment, so wouldn't have ' instead of '.

One more small fix to remove the <br /> on edit a comment

A bit of scope creep here, I'll probably create a separate issue to focus on the checkout pane in checkout as this is a bit hard to review.
The patch here for example dispatches an event on pane submission, but the user could go back and edit the comment?

I haven't tested the patch manually, but it doesn't seem that editing the comment is supported.
I'm thinking we should store the comment in the order data for example, and only record the log on checkout completion / order placement.

Created #3468080: Provide a checkout pane for customer comments.

I'm getting following error after installing patch 39 (previous patches not patching with my version of commerce 2.40.0 and drupal 10.3.6

TypeError: Drupal\commerce_log\EventSubscriber\OrderEventSubscriber::__construct(): Argument #2 ($order_receipt_mail) must be of type Drupal\commerce_order\Mail\OrderReceiptMailInterface, Drupal\symfony_mailer\MailManagerReplacement given, called in /home/[workingdir]/core/lib/Drupal/Component/DependencyInjection/Container.php on line 261 in Drupal\commerce_log\EventSubscriber\OrderEventSubscriber->__construct() (line 40 of /home/[workingdir]/modules/contrib/commerce/modules/log/src/EventSubscriber/OrderEventSubscriber.php).

any help / pointers gratefully received as client strongly relies on this functionality which has stopped working since upgrades.

Patch #41 no longer applied against the latest version 3.3.2

Re-rolled the patch for the latest 3.x.
Please, test.

Created patch with the latest fixes in new MR for 3.x

I reviewed this quickly today and I find it impractical that we'd resend the order receipt each time. Also, what about "from customer comments"? For a few releases now, we have a "customer_comments" field.

We've discussed the idea of implementing this feature from contrib instead (via the commerce_email module), but this alternate approach requires further research.

@jsacksick: Could you explain what you find impractical a bit more? The order receipt is *not* sent "each time" - it is ONLY sent if the admin has checked "Notify the customer". The order receipt template is used so the customer knows exactly what order, and products, are being commented on. The goal is the customer should have all the info they need *in this singular email* without having to check previous emails or having to return to the site.

> For a few releases now, we have an "customer_comments" field.

This field is used for comments *from the customer to the admin*. This patch is *the other way* - from the admin to the customer, by way of documentation on the order. We wouldn't want to reuse the customer_comments field for that (nor is that customer comments field currently exposed in the UI after the order is placed, for either the customer or the admin).

commerce_email feels like a bit of a weird place to put this, since that's all about reacting to _existing events_ with _automated emails_, and this particular action is an admin manually adding an order comment that they may or may not consider important enough to email the customer about.

We wouldn't want to reuse the customer_comments field for that (nor is that customer comments field currently exposed in the UI after the order is placed, for either the customer or the admin).

Yes, I know, but the MR adds a new from customer event:

/**
* Name of the event fired after customer adds a checkout comment to an order.
*
* @Event
*/
const ORDER_FROM_CUSTOMER_COMMENT = 'commerce_order.comment.from_customer'

This new event isn't fired anywhere.

The order receipt is *not* sent "each time" - it is ONLY sent if the admin has checked "Notify the customer".

Yes, what I meant by "each" time, is each time a new comment is added from the admin and "Notify the customer" is checked.
I hear the point about keeping the comment in context, just questioning whether this is really the best thing to do, or we could simply have a new template that says "A new comment was added to your order #xxxx" or something, with a link to the customer order view page or wherever the customer can reply.

The commerce_email approach was briefly discussed, we aren't entirely sure it will work yet.

Yes, I know, but the MR adds a new from customer event:

Ah. Huh. It appears to be used less as an event and more as a log type ID, to determine which comment is which ("from customer" vs. "to customer") and to differentiate between those two in the theme layer. For our internal purposes, AFAIK, we don't use it as an event either.

I hear the point about keeping the comment in context, just questioning whether this is really the best thing to do, or we could simply have a new template that says "A new comment was added to your order #xxxx" or something, with a link to the customer order view page or wherever the customer can reply.

Some comments on this:

• It'd be A-OK with me if you want to default the theme to "click here to read the comment", as long as site devs can still override that default theme to make it look-and-feel like the order receipt email. It's important to us that the information is in the email, and the email is as complete a record as possible, as we do often have repeat buyers, especially during the heavier academic seasons.
• Of the 50 or so sites currently using this patch, a dozen or so of them are "API only" sites. A purchasing customer visits publisher's SITE A which is running on a different server, in a different technology, and which offers its own catalog and their own internal integrations. Publisher's SITE A then contacts Drupal Commerce SITE B over JSON:API to handle the production, distribution, and email communication of the order. A purchasing customer never see SITE B. They have no idea SITE B exists, nor does SITE B offer a public UI. "Click here to read the comment" is dead-on-arrival on these "API only" sites. (Thus why all relevant information must be in the email.)
• Note, also, that this patch as written is *not a conversation*. Purchasing customers leave a ("from customer") comment once, when they are checking out the order. After that, they can never leave a comment on that order again (with or without this patch). The admin customer-facing comments with notification ("to customer") that this patch provides are more intended as personable status updates on the order - stuff like "we are on vacation and will start making your order next week" or "your order has recently shipped and your tracking number is ..." or "thank you so much! you're gonna love it!". There is no expectation that, or need for, a customer to reply to a message.

Added a static patch compatible with version 3.3.4, as MR 637 is no longer applicable.