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