-
Notifications
You must be signed in to change notification settings - Fork 368
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
Add jobs pending payment to the Jobs dashboard #2141
base: trunk
Are you sure you want to change the base?
Conversation
@@ -418,6 +418,10 @@ public function get_job_actions( $job ) { | |||
break; | |||
case 'pending_payment': | |||
case 'pending': | |||
$actions['continue'] = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might need to split pending
and pending_payment
here. pending
is if they've actually submitted it but pending_payment
is before the process. Edit
(when available based on setting) makes more sense for pending
and pending_payment
.
We should probably put this in an action under default:
, but somehow not break compatibility with older WCPL that don't hook into the new action.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I agree, and IMO it should set the status back to Draft to actually have the listing go through the status transitions when they actually occur. Reason being the listing should go into preview
status again, then transition to pending_payment
(instead of just remaining on pending_payment
through the entire flow)
@@ -268,7 +268,7 @@ private function is_job_available_on_dashboard( WP_Post $job ) { | |||
private function get_job_dashboard_query_args( $posts_per_page = -1 ) { | |||
$job_dashboard_args = [ | |||
'post_type' => 'job_listing', | |||
'post_status' => [ 'publish', 'expired', 'pending', 'draft', 'preview' ], | |||
'post_status' => [ 'publish', 'expired', 'pending', 'draft', 'preview', 'pending_payment' ], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably hook into job_manager_get_dashboard_jobs_args
from WCPL.
@yscik and @jom -- really glad to see this being moved on! I've been using Gnodesign's snippets to achieve this on a very active job board, and wanted to chime in from our experience:
Having the job package duplicated at checkout is problematic--it is not an unusual occurrence on our job board where our users don't notice such a duplication and place an order for twice as much as they intended to and then have to follow-up with us for a refund (leaving a bad taste in their mouth, and causing extra work on all sides). On the other hand, having their WooCommerce cart unexpectedly cleared of other job packages (like job posts they wanted to purchase in advance from the WooCommerce product pages) or other products they'd added to it would also be confusing to users (and job board operators who don't know that this is expected behavior). I think an ideal solution would be that any job package that has an attached Job Listing with an identical title is removed--i.e. just removing what would be the duplicate job package.
I think it's important that the user is able to still view and edit the submission, and that it doesn't just take them straight to checkout. It is common on our job board that a user abandons a job post on the "Choose a Package" page or checkout page, and when coming back to continue its submission wants to verify the details of the job post and/or edit it before submitting it. UPDATE: one additional reason added in comment below. Side note, in case this is also relevant: when the "Paid Listings Flow" is "Choose a package after entering job details," as on my site, and a user takes a job post to the "Choose a Package" page and then abandons it, the job post is listed as "Pending Payment" but is not added to the cart (since a package hasn't been chosen yet). Pending Payment job packages are only added to the cart after a package is selected and the "Submit" button is hit on the "Choose a Package" page. Lastly, we also realized that having job posts labeled as "Pending Payment" on the front-end is alarming to users--our users saw this, and were concerned that they were going to be getting an invoice or have their card billed, so we actually re-labeled the "Pending Payment" status to "Draft" on the front-end user dashboard, which I would strongly encourage doing. After all, an abandoned job post is not "Pending Payment", it really is still just a "Draft" (for the user, at least), and I think this is the correct label for it (at least on the front-end for users). I hope this is helpful, and want to offer that I am happy to contribute in whatever way I can with this (beyond coding, which I don't have your skills at, unfortunately)! |
Another reason that continuing submission of a "Pending Payment" job post should take the user to the job post submission form (and not skip to a later page, like going directly to checkout) is that users will often abandon a job post because they chose the wrong job package for it (or change their mind about what package to use or purchase), and so users will want the option of choosing a different package when continuing submission of a "Pending Payment" job post. |
Thanks @Hastibe for the additional insight! I'm thinking we could add a Cart section with packages already in cart to the package selection screen — that way the user could see if they already have a package, and make an explicit choice to use that or add a new one. I'm not sure labeling Pending payment submissions as Draft is good idea, as they'll behave differently (eg activate when the user ends up finishing the checkout). |
I posted a comment on Gino's open issue about this, but IMO we should add a different action than the standard I think we should add a new action that will actually set the listing back to Otherwise the listing will always just stay in the |
You're welcome, @yscik!
Hmm! So, you would have the package selection page look something like the following below? Your Packages:
In Cart:
Purchase Package:
Let's say I had abandoned "Example Job" on the checkout page, but then gone back to the dashboard, clicked "Continued Submission" on it and made edits to it, and now wanted to submit it as a "Regular Job Post"--would I select it from the option under the "In Cart" section (or would this not have the edits I made to it?) or under the "Purchase Package" section, or wouldn't it matter? After making a selection on the "Choose a Package" page and continuing to the checkout page, would the cart be cleared, except for the "In Cart" or "Purchase Package" option that I'd chosen, or would the checkout page still have the three items in my cart (plus any package purchase selection I had made on the "Choose a Package" page)?
This is a bit of an aside, since I imagine it would be easy for me to re-label job statuses to anything I want via a translate function, but from a user perspective, wouldn't a Pending Payment job and a Draft job behave the same, though? The only place they are going to see the status of them is on their dashboard, where they both aren't submitted yet and have a "Continue Submission" option, which if used to take them to checkout, will activate either of them. I guess, if the user had previously taken the Pending Payment job not just to the "Choose a Package" page, but to the checkout page, and then did eventually checkout with that job in the cart, that job will activate (whereas the Draft job wouldn't show-up in the cart, of course), but I still think you could have the Pending Payment job labeled as a Draft, and it would be a more understandable status for the user to see, without causing any user confusion or other problems. This is because I think a user would reasonably assume that a "Draft" (actually Pending Payment) job that is in their cart would activate after they complete checkout for it (I mean, who wouldn't, right?), so I still don't see the existence of the Pending Payment status on the front-end as making any helpful distinction from the Draft status to a front-end user. |
Changes proposed in this Pull Request
pending_payment
status in the job dashboardContinue Submission
action to pending jobsTesting instructions
Continue Submission
to try againKnown issues
— should we clear the cart?
— should this be more clever, and direct the user to the checkout if there is a related package in the cart?
(in both cases the action should likely move to the paid listings plugins)