User story:
As a new merchant
I want to focus on the most important setup tasks
So I can review some details later
Description: with Jetpack installed and connected, alongside WCS, we have the opportunity to set things up on the users' behalf, and ask them to review and confirm, rather than start from scratch and think.
Acceptance Criteria:
Event tracking:
We can use the event wcadmin_tasklist_task_completed and eventually add a new value to task_name when this happens: shipping_automated
Additional links:
Design mockup
I don't know what would be involved in configuring WCS with shipping zones and printing shipping labels.
Notification estimate: 1
Prior art for updating shipping zones can be found in the shipping task:
Because iterating over all shipping zones and checking against store defaults can get complicated quickly, I think we should only set these default shipping zones if no previous zones existed.
We can use the event wcadmin_tasklist_task_completed and eventually add a new value to task_name when this happens: shipping_automated
@pmcpinto If it's okay, we can use a new event for this automation. The way we're currently able to track tasks that were completed outside the task list does not let us easily pass in custom events parameters.
Chiming in with another extensible approach on this one too :)
With the fulfill focus actively working and iterating in the shipping space, would it make more sense to make the shipping step more extensible and open the door for WCS, and other shipping extensions, to build out rich defaults like this within their own extension logic?
To me this feels a bit more flexible in the long run, as it would allow WCS to update the logic as their code changes... if we implement a "hard coded" solution like this, we could potentially be venturing down a path where we could hit compatibility issues with WCS - or not be using the latest/greatest offerings from the extension.
So again perhaps we could look at making the shipping tasks filterable, and allow for extensions to inject their own setup flows here too. This would also offer for added flexibility in the ecommerce plan.
would it make more sense to make the shipping step more extensible and open the door for WCS, and other shipping extensions,
I'm always a 馃憤 for extensibility 馃槃
I think the extensibility in this case may not happen directly in the shipping step though. I was thinking more along the lines of profiler completion as this feels a little safer than having to visit the step in order for the logic to run.
Currently this is trivial to run on the update_option_woocommerce_onboarding_profile hook and check for completion, but we could introduce a vanity action specific to this.
do_action( 'woocommerce_onboarding_profile_completed' );
Or did you have something else in mind on where/how this should run @timmyc?
@pmcpinto If it's okay, we can use a new event for this automation. The way we're currently able to track tasks that were completed outside the task list does not let us easily pass in custom events parameters.
Yep sure, I'm good with a new event
I'd estimate a 2.
Hey @pmcpinto!
automatically turn on print shipping labels (I think this is already happening)
This is happening, when Jetpack is connected.
I'm having a problem implementing this where Jetpack has to be connected in order to add the local shipping method and add the notification as you've specified:
If the store has JP installed and connected, WCS active...
Since Jetpack isn't connected until after the OBW completes, triggering adding the local shipping method and adding the notification never happens.
I think since turning on the shipping labels is done automatically elsewhere we don't have the requirement for Jetpack and WCS any more and those checks can just be removed. Do you agree?
I think since turning on the shipping labels is done automatically elsewhere we don't have the requirement for Jetpack and WCS any more and those checks can just be removed. Do you agree?
Yep. That makes complete sense. Thanks!
Most helpful comment
Chiming in with another extensible approach on this one too :)
With the fulfill focus actively working and iterating in the shipping space, would it make more sense to make the shipping step more extensible and open the door for WCS, and other shipping extensions, to build out rich defaults like this within their own extension logic?
To me this feels a bit more flexible in the long run, as it would allow WCS to update the logic as their code changes... if we implement a "hard coded" solution like this, we could potentially be venturing down a path where we could hit compatibility issues with WCS - or not be using the latest/greatest offerings from the extension.
So again perhaps we could look at making the shipping tasks filterable, and allow for extensions to inject their own setup flows here too. This would also offer for added flexibility in the ecommerce plan.