Added notification emails and basic scheduling logic #648

peterfabian · 2024-08-05T11:40:49Z

First POC that contributes towards #645

Description

This is a WIP to add notifications to Subscriptions Core.

Currently, it

adds simple email templates,
adds email-related classes,
registers these classes,
adds simple scheduling logic for actions that should trigger the email with pre-defined offset (3 days)

Mostly, it's inspired by code that's already in Subscriptions Core.

Notification Types Added

Auto Renewal
- scheduled {{time_offset}} ahead of $subscription->get_date( 'next_payment' ) for automatically renewing subscriptions ($subscription->is_manual() is false)
Manual Renewal
- scheduled {{time_offset}} ahead of $subscription->get_date( 'next_payment' ) manual subscriptions ($subscription->is_manual() is true)
Trial Expiry
- scheduled {{time_offset}} ahead of $subscription->get_date( 'trial_end' ) manual subscriptions
Subscription End
- scheduled {{time_offset}} ahead of $subscription->get_date( 'end' ) manual subscriptions

Open Questions

Some questions that crossed my mind while implementing this:

We need to decide where to put filters/actions to allow extensibility
I could have added the schedules to WCS_Action_Scheduler, but it seemed more appropriate to create a new class for notifications (WCS_Action_Scheduler_Customer_Notifications ), otherwise the scheduling logic might be a bit complex. It should be quite easy to change this, though.
The scheduling logic currently uses the state of the subscription object instead of deciding depending on which date/status is being updated. It was easier to grasp for me, given my inexperience with Subscriptions, but again, it should be possible to convert this to an approach similar to WCS_Action_Scheduler that relies entirely on Subscription status and which date is being updated (combining the logic of get_scheduled_action_hook, update_status and update_date methods).
Should we send a payment notification for trial expiry (in addition to trial expiry notification)?
Which conditions we want to check at schedule time vs at the time of sending the notification?
Do we want to unschedule notifications when store manager disables them?
- Most likely not, as it's a lot of work to schedule/unschedule all of them. If they're disabled, this will create clutter in the db, though.

Side Notes

I had to downgrade to node 16 to build it
I had problems committing as phpcs was giving me errors. I updated ControlStructureSpacingSniff.php (converted last argument to array for ExtraSpaceBeforeCloseParenthesis and ExtraSpaceAfterCloseParenthesis sniffs), otherwise phpcs was failing. Perhaps there's a better way to solve this, but I didn't want to spend too much time investigating what's going on and what array should be passed where it gets a string. Updating squizlabs/php_codesniffer to 3.10.2 didn't help either.
- it seems like this has been fixed in the latest WP sniffs, so maybe updating some composer packages would resolve this (like the old WC sniffs?)

TODO

Add trigger to send the emails automatically
- Add order note when an email is sent
- Respect when the site is staging site and other exclusions
Surface the day offset setting in the WC settings
Add trigger to send a notification manually from order/subscription edit screen
etc etc

How to test this PR

Create a couple of different types of subscriptions: simple, variable, with free trial, with defined end-date/length, with free trial and length
Buy these subscriptions, update them, renew them manually and automatically, cancel them.
See if the notifications are being (un)scheduled as expected.

Added changelog entry (or does not apply)
Will this PR affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
Will this PR affect WooCommerce Payments? yes/no/tbc, add issue ref
Added deprecated functions, hooks or classes to the spreadsheet

xristos3490

Amazing work, @peterfabian! Loved how you incorporated the WCS_Scheduler structure and the date types! Everything seem to be falling into place 🙌

Left some initial thoughts on the structure before I start doing some hands-on testing.

includes/class-wcs-core-autoloader.php

includes/class-wcs-action-scheduler-customer-notifications.php

xristos3490 · 2024-08-05T12:14:03Z

includes/class-wcs-action-scheduler-customer-notifications.php

+		unset( $date_types_to_schedule['start'] );
+
+		//TODO: filter?
+		$this->date_types_to_schedule = array_keys( $date_types_to_schedule );


Sounds good to me! An internal filter would be helpful for quickly managing active notifications "types"

If we do add one, we need to reuse it within each email's trigger function to handle existing records before applying that filter. It's a small "gap" but has a simple solution.

This might also concern the global toggle of this feature. Since it is initially disabled, we need a reliable method to control its access. Adding a filter here could introduce some complexity, but there is a crucial difference between this class and the WCS_Action_Scheduler, in that this class requires a toggle to enable or disable the feature. 🤔

A follow-up question here would be related to how we handle this "global toggle." Should that be a checkbox? Or should we consider an empty value in the "days input" to indicate that it is disabled? I lean more toward the latter option.

As I'm looking at it, I can see the emails in Woo have their own toggle for enabling/disabling, maybe we can reuse that (and if we provide a global disable, we can just set this toggle for all notifications?)

Yeah, we probably don't need a filter here at this point.

I also think that we could pass the date type into the days-getter-filter and allow developers to disable specific types (e.g., by returning 0.)

Related question: Should we schedule notifications for disabled emails (based on the UI toggle)? I think we still should. This is different from disabling by returning 0 from the filter above, as we cannot schedule "0 days before the event".

Should we schedule notifications for disabled emails (based on the UI toggle)? I think we still should.

Yes, I think we should and the code indeed does that.

includes/class-wcs-action-scheduler-customer-notifications.php

…ubscription settings.

…ttic/woocommerce-subscriptions-core into try/subs-notifications-pf

james-allan · 2024-08-21T07:52:41Z

includes/class-wcs-action-scheduler-customer-notifications.php

+		if (
+			! (
+				$subscription->has_status( 'active' )
+				|| $subscription->has_status( 'pending-cancel' ) //TODO: do we want to create notifications when user cancelled the subscription?


do we want to create notifications when user cancelled the subscription?

I think we'll need to test that to confirm but I don't think we would.

For some background the WCS_Scheduler hooks into both subscription date and status updates.

When a subscription date is updated, we schedule the related AS event.
When a subscription status is changed, we unschedule any events that are no longer applicable to that status and schedule events that are. eg putting a subscription on-hold cancels the payment event. Reactivating a subscription reschedules the next payment date.

I think this notification class should follow a similar principle.

So to answer the question then I don't think we do need to create notifications on the cancelled event because when a customer cancels the subscriptions, we calculate the end date and schedule the end date. The scheduling of that date is what should trigger the notification to be scheduled, not the status transition itself.

Thanks for elaborating. My todo comment was added to clarify whether we want to notify the customer about the upcoming expiry if they manually canceled the subscription (and thus should be aware that it's expiring).

My todo comment was added to clarify whether we want to notify the customer about the upcoming expiry if they manually canceled the subscription (and thus should be aware that it's expiring)

Oh right. I think the answer is yes, even if the customer initiated the cancellation, we'd still want to send the pre-cancel email. The reason is that they may have cancelled the subscription weeks or months earlier and so notification of it being finally cancelled.

james-allan · 2024-08-21T08:02:09Z

includes/class-wcs-action-scheduler-customer-notifications.php

+		$dt->sub( new DateInterval( "PT{$this->get_hours_offset( $subscription )}H" ) );
+
+		return $dt->getTimestamp();
+	}


I might be missing the rest of the context here but I'm wondering if we should just use the number of seconds and timestamps?

I noticed that the setting (interval and period) is being converted into hours and I'm wondering if it would be easier to convert it into seconds and then just do a straight subtraction.

Seems like a good idea to me. Working with seconds allows us more granular control.
Also, since both the subscription's get_date() and the AS work in UTC by default, we should be aligned. Right?

I generally prefer to work with standard DateTime classes when available to avoid some of the pitfalls mentioned here https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca, but I suppose using timestamps would be easier here and should be ok.

james-allan · 2024-08-21T08:05:32Z

includes/class-wcs-action-scheduler-customer-notifications.php

+
+			if ( $subscription->get_date( 'next_payment' ) ) {
+				$this->schedule_payment_notification( $subscription );
+			}


This could be right but wanted to double check. When a subscription's date is updated you reschedule all dates?

eg if the next payment date is updated, it would pass the in_array() check and then all subscription dates would be rescheduled.

When a subscription's date is updated you reschedule all dates?

Yes. If the scheduling is correct, nothing is written to the db, but the code currently checks whether the scheduling is correct for all 3 types of notifications (and fixes it if it isn't).

james-allan · 2024-08-21T08:07:36Z

includes/class-wcs-action-scheduler-customer-notifications.php

+	 * @param string $date_type Can be 'trial_end', 'next_payment', 'end', 'end_of_prepaid_term' or a custom date type
+	 */
+	public function delete_date( $subscription, $date_type ) {
+		$this->update_date( $subscription, $date_type, '0' );


Just noting that the 3rd param isn't used in update_date(). It might still work though. Just wanted to flag as I skimmed :)

What do you mean it might still work? 😄
I'm old-school, so if a method is declared with 3 arguments, I provide 3 arguments.

Jokes aside, I removed the call as I updated the logic when notifications get scheduled.

I'm also reading my comment and wondering what I meant by "it might still work". 🤔 😆

I think I took that a function called delete_date() calling a function update_date() with 0 as a param to mean that passing 0 would cause the update_date() call to behave in a sort of delete mode.

I was flagging that the third param in this version of update_date() isn't used and therefore '0' couldn't cause it to work in a delete mode.

I think I was noting that I would need to come back to this. After looking at it a little deeper I don't know if I can tell there is a problem here. When a date is deleted, it will eventually call schedule_all_notifications() and that function only schedules notifications if a date exists. eg

if ( $subscription->get_date( 'next_payment' ) ) { $this->schedule_payment_notification( $subscription ); }

Because the date is deleted, that if condition would fail and it wouldn't schedule an event. That might be correct, but wouldn't we need to unschedule a related event if a relevant date is deleted?

The way to test this I guess would be to have a subscription with a next payment date and a pre-renewal event scheduled. Then call $subscription->delete_date( 'next_payment' ) and see if it correctly unschedules the event.

james-allan

This looks pretty good @peterfabian. I haven't had a chance to test it today, however I've given it a skim in terms of reviewing the general approach taken.

I left some initial comments. :)

Just a heads up. I noticed in the PR array(). We have switched to use the shorthand syntax ([]) however haven't updated all existing uses. Our current approach is to use [] in newer code.

james-allan · 2024-08-21T08:08:16Z

includes/class-wcs-action-scheduler-customer-notifications.php

+
+				break;
+			case 'pending-cancel':
+				// Unschedule all notifications?


I don't think you would want to unschedule all, I think the expiration one is still one you'd want.

To allow easier batch processing, notifications are updated whenever subscription is updated after the settings changed, if the previous update of the subscription was before the settings changed.

Checking for the changes in the generic hook seems too fragile.

includes/class-wcs-action-scheduler-customer-notifications.php

* Initial batch processing POC. * Update setting timestamp when the global switch is flipped. * Trigger batch when settings change. * Added update/schedule vs unschedule to batch process. * Introduce the Notifications Scheduler Debug Tool (#673) * Introduce the debug tool processor * Cleanup batch processor * Add the tool * Fix typo * Add unit tests * More unit tests --------- Co-authored-by: Chris Lilitsas <[email protected]>

…ded.

james-allan

Hey @peterfabian and the rest of the team working on this! 💯

Really nice work here. It's a monster of a PR to review.

I left a few inline comments but I'm happy if you want to turn those into issues so we can move forward with smaller issues and bug fixes.

A couple of general things I noticed that I thought were worth raising.

$subscription->get_time() returns a subscription date as a timestamp. I noticed in a couple of places where a datetime object is being created from the get_date() mysql formatted value, and then converting into a timestamp via getTimestamp(). I'm curious if that's by design or if the approach taken in get_time() isn't correct or there's a preference with it. I ask because in general it would be my preference to use the established helpers to get subscription dates as a timestamp format rather than have multiple places where date formats are converted just from a DRY principle.
Function block comments. I noticed there's a few functions missing function block comments. Understandably so given the size of the PR. I left a few inline comments before realising it's more widespread. Just wanted to flag it incase you respond to those inline comments. But as I mentioned, I'm happy to move forward and address that separately rather than hold up this PR on such a minor technicality. :)

james-allan · 2024-09-19T03:36:10Z

includes/admin/debug-tools/class-wcs-notifications-debug-tool-processor.php

+		return array_map( 'wcs_sanitize_subscription_status_key', $allowed_statuses );
+	}
+
+	public function get_total_pending_count(): int {


Minor: This function is missing a function comment.

james-allan · 2024-09-19T03:42:33Z

includes/admin/debug-tools/class-wcs-notifications-debug-tool-processor.php

+	}
+
+	/**
+	 * Start the background process for coupon data conversion.


Suggested change

* Start the background process for coupon data conversion.

* Start the background process for batch processing subscription notifications updates.

Looks like a copy-paste.

james-allan · 2024-09-19T03:45:22Z

includes/admin/debug-tools/class-wcs-notifications-debug-tool-processor.php

+	}
+
+	/**
+	 * Stop the background process for coupon data conversion.


Suggested change

* Stop the background process for coupon data conversion.

* Stop the background process for batch processing subscription notifications updates.

james-allan · 2024-09-19T03:50:07Z

includes/class-wc-subscriptions-email-notifications.php

+/**
+ * Subscriptions Email Notifications Class
+ *
+ * Some details to enlighten your exploration of this code.


Suggested change

* Some details to enlighten your exploration of this code.

Were there supposed to be details that enlighten my exploration ? 😄

james-allan · 2024-09-19T03:51:38Z

includes/class-wc-subscriptions-email-notifications.php

+
+		add_filter( 'woocommerce_order_actions', [ __CLASS__, 'add_notification_actions' ], 10, 1 );
+
+		// TODO this is a bit ugly...


Agreed. We generally don't like using closures/anonymous functions especially attached to callbacks but we can address this separately if you're eager to merge this big PR.

james-allan · 2024-09-19T07:00:29Z

includes/emails/class-wcs-email-customer-notification-subscription-expiration.php

+
+		$this->heading = __( 'Subscription Expiring Notification', 'woocommerce-subscriptions' );
+		// translators: placeholder is {blogname}, a variable that will be substituted when email is sent out
+		$this->subject = sprintf( _x( '[%s] Subscription is about to expire', 'default email subject for cancelled emails sent to the admin', 'woocommerce-subscriptions' ), '{blogname}' );


Suggested change

$this->subject = sprintf( _x( '[%s] Subscription is about to expire', 'default email subject for cancelled emails sent to the admin', 'woocommerce-subscriptions' ), '{blogname}' );

$this->subject = sprintf( _x( '[%s] Subscription is about to expire', 'default email subject for upcoming subscription expiration emails sent to the customer', 'woocommerce-subscriptions' ), '{blogname}' );

james-allan · 2024-09-19T07:01:59Z

includes/emails/class-wcs-email-customer-notification.php

+			$order_note_msg = sprintf( __( '%1$s was successfully sent to %2$s.', 'woocommerce-subscriptions' ), $this->title, $this->recipient );
+		} else {
+			/* translators: 1: Notification type, 2: customer's email. */
+			$order_note_msg = sprintf( __( 'Attempt to send %1$s to %2$s failed successfully.', 'woocommerce-subscriptions' ), $this->title, $this->recipient );


Suggested change

$order_note_msg = sprintf( __( 'Attempt to send %1$s to %2$s failed successfully.', 'woocommerce-subscriptions' ), $this->title, $this->recipient );

$order_note_msg = sprintf( __( 'Attempt to send %1$s to %2$s failed.', 'woocommerce-subscriptions' ), $this->title, $this->recipient );

A successful failure. 🤔

james-allan · 2024-09-19T07:04:14Z

templates/emails/customer-notification-auto-renewal.php

+		echo wp_kses(
+			sprintf(
+				// translators: %1$s: name of the blog.
+				_x( 'Your subscription for XYZ on %1$s will be renewed automatically. Thanks for being a loyal customer with us!', 'In customer renewal invoice email', 'woocommerce-subscriptions' ),


I'm assuming xyz is a placeholder for now but is that going to be the product or something else?

Just curious because for subscriptions with multiple items, it could get unwieldy.

james-allan · 2024-09-19T07:26:38Z

templates/emails/customer-notification-expiring-subscription.php

+		echo wp_kses(
+			sprintf(
+			// translators: %1$s: name of the blog, %2$s: link to checkout payment url, note: no full stop due to url at the end
+				_x( 'Your subscription for XYZ on %1$s is about to expire. To keep receiving the goodies, renew it over here: %2$s', 'In customer renewal invoice email', 'woocommerce-subscriptions' ),


I apologise if I've missed it, but we may need to consider a different word other than "renew".

WooCommerce Subscriptions uses renew to describe the regular scheduled payments for a subscription. Subscriptions renew every month for example, but they only expire at their predetermined end date.

Subscriptions expire (end automatically after x periods). eg $14/month for 12 months. After the 12 months, the subscription will automatically expire and the customer would need to resubscribe - not renew.

Also, linking the customer to the subscription's checkout payment URL wouldn't work. That would send them to a URL like this /checkout/order-pay/9269/?pay_for_order=true&key=wc_order_U168PYBA4ixPl which is an empty pay for order page.

TBH I'm not sure what the CTA would be for an upcoming subscription expiration because until it's expired, there's not a lot they can do. Once it is expired, they can resubscribe.

james-allan · 2024-09-19T07:30:15Z

templates/emails/customer-notification-manual-renewal.php

+			echo wp_kses(
+				sprintf(
+					// translators: %1$s: name of the blog, %2$s: link to checkout payment url, note: no full stop due to url at the end
+					_x( 'Your subscription for XYZ on %1$s is about to expire. To keep receiving the goodies, renew it manually over here: %2$s', 'In customer renewal invoice email', 'woocommerce-subscriptions' ),


Similar feedback to above. Expire in WooCommerce Subscriptions means end. We may prefer to use "expire" in this customer facing way because that makes sense to customers -- in which case this feedback can be ignored. 😅

Perhaps something like

"You subscription for xyz on %1$s is nearly due for renewal. To keep receiving..."

The CTA is also not likely to work here either because the renewal order wouldn't have been created yet and so they would need to wait until the renewal is created in order to pay for the renewal. There's a renewal invoice email that would be sent for that purpose.

Initial work.

33f9f7e

peterfabian self-assigned this Aug 5, 2024

peterfabian added 2 commits August 5, 2024 13:51

Linting fix.

6de19d2

Small improvements after rereading.

3a78c28

xristos3490 reviewed Aug 5, 2024

View reviewed changes

peterfabian added 15 commits August 5, 2024 15:13

Consistent naming of actions.

7078d87

Consistent naming of classes and files.

2aaf7e5

Added email triggers and simple check on action execute.

9c5284d

Handle reactivation correctly.

8f8cda8

Added order notes and actions.

ab9085e

Add get/setter for hours offset and a filter.

b614a4e

Made the change to autoloader less intrusive.

ab517ff

Removed todo after discussion.

41ea0c7

Make behavior of enable/disable notifications consistent with other S…

5a2dc00

…ubscription settings.

Added settings UI.

ade0f50

Merge branch 'trunk' into try/subs-notifications-pf

e43558e

Made the setting work.

707a4d2

Merge branch 'try/subs-notifications-pf' of https://github.com/Automa…

6afaabe

…ttic/woocommerce-subscriptions-core into try/subs-notifications-pf

Display only relevant actions for manual trigger.

ffffa8f

Allow the offset to be set based on subscription properties.

2dc1630

james-allan self-requested a review August 19, 2024 00:16

james-allan reviewed Aug 21, 2024

View reviewed changes

peterfabian added 4 commits September 4, 2024 10:41

Update notifications logic change.

31d38b6

To allow easier batch processing, notifications are updated whenever subscription is updated after the settings changed, if the previous update of the subscription was before the settings changed.

Merge branch 'trunk' into try/subs-notifications-pf

40750e8

Added docs for new methods.

12dd88e

Short array syntax.

5689328

peterfabian added 8 commits September 4, 2024 10:52

Don't unschedule expiry notification when subscription is cancelled.

a6aef48

Fixing docs.

6a6e3ff

Change time offset to seconds.

a36b661

We still need those extra scheduling triggers.

a2f613c

Checking for the changes in the generic hook seems too fragile.

Small refactor.

061ded4

Handle the case when subscription has neither modified, nor create date.

da96aa8

Improved docs.

1e2d51b

Docs updated.

c240ace

xristos3490 reviewed Sep 4, 2024

View reviewed changes

includes/class-wcs-action-scheduler-customer-notifications.php Show resolved Hide resolved

peterfabian and others added 18 commits September 6, 2024 10:56

One renewal notification action should be enough for everyone.

7f1eca1

Use the getter instead of direct access.

2bd7638

Added checkbox to enable/disable notifications.

bc80cb1

Don't send notifications if globally disabled.

fe361e6

No notifications if subscription period is too short..

43505cf

Added AS group name to notifications.

3a32f2a

Merge branch 'trunk' into try/subs-notifications-pf

213901f

Don't schedule notifications if the killswitch is off.

094ce09

enable feature in tests

e467775

Move subscription_period_too_short as the email class often isn't loa…

51ca698

…ded.

Fix unit

2e7ce00

Fix units (2)

aa03ca3

Make get_action_args static, as it doesn't depend on instance.

39b61e1

Handle conflict between trial end and next payment notification.

e01046b

Improved settting wording.

97a9198

Made settings consistent.

956d3f3

Merge branch 'trunk' into try/subs-notifications-pf

f6bb953

james-allan reviewed Sep 19, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added notification emails and basic scheduling logic #648

Added notification emails and basic scheduling logic #648

peterfabian commented Aug 5, 2024 •

edited

Loading

xristos3490 left a comment •

edited

Loading

xristos3490 Aug 5, 2024

xristos3490 Aug 5, 2024

peterfabian Aug 5, 2024

xristos3490 Aug 5, 2024 •

edited

Loading

peterfabian Sep 4, 2024

james-allan Aug 21, 2024

peterfabian Sep 4, 2024

james-allan Sep 19, 2024

james-allan Aug 21, 2024

xristos3490 Sep 2, 2024

peterfabian Sep 4, 2024 •

edited

Loading

james-allan Aug 21, 2024

peterfabian Sep 4, 2024 •

edited

Loading

james-allan Aug 21, 2024

peterfabian Sep 4, 2024

james-allan Sep 19, 2024

james-allan Sep 19, 2024

james-allan left a comment

james-allan Aug 21, 2024

james-allan left a comment

james-allan Sep 19, 2024

james-allan Sep 19, 2024

james-allan Sep 19, 2024

james-allan Sep 19, 2024

james-allan Sep 19, 2024

james-allan Sep 19, 2024

james-allan Sep 19, 2024

james-allan Sep 19, 2024

james-allan Sep 19, 2024

james-allan Sep 19, 2024

	* Start the background process for coupon data conversion.
	* Start the background process for batch processing subscription notifications updates.

	* Stop the background process for coupon data conversion.
	* Stop the background process for batch processing subscription notifications updates.


		add_filter( 'woocommerce_order_actions', [ __CLASS__, 'add_notification_actions' ], 10, 1 );

		// TODO this is a bit ugly...

	$this->subject = sprintf( _x( '[%s] Subscription is about to expire', 'default email subject for cancelled emails sent to the admin', 'woocommerce-subscriptions' ), '{blogname}' );
	$this->subject = sprintf( _x( '[%s] Subscription is about to expire', 'default email subject for upcoming subscription expiration emails sent to the customer', 'woocommerce-subscriptions' ), '{blogname}' );

	$order_note_msg = sprintf( __( 'Attempt to send %1$s to %2$s failed successfully.', 'woocommerce-subscriptions' ), $this->title, $this->recipient );
	$order_note_msg = sprintf( __( 'Attempt to send %1$s to %2$s failed.', 'woocommerce-subscriptions' ), $this->title, $this->recipient );

Added notification emails and basic scheduling logic #648

Are you sure you want to change the base?

Added notification emails and basic scheduling logic #648

Conversation

peterfabian commented Aug 5, 2024 • edited Loading

Description

Notification Types Added

Open Questions

Side Notes

TODO

How to test this PR

xristos3490 left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xristos3490 Aug 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

peterfabian Sep 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

peterfabian Sep 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

james-allan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

james-allan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

peterfabian commented Aug 5, 2024 •

edited

Loading

xristos3490 left a comment •

edited

Loading

xristos3490 Aug 5, 2024 •

edited

Loading

peterfabian Sep 4, 2024 •

edited

Loading

peterfabian Sep 4, 2024 •

edited

Loading