Request for verified only

Hi Ihor.

  1. Please suggest a snippet that requests with the attribute “for verified” (you can make any other) are only seen by verified sellers, with the icon verified…
    It will help me a lot in further promotion, as there are many features missing when working with queries.

  2. For example, it would be ideal to limit the number of seller offers on user requests to 1 or another number. That it would be possible to create packages to buy the number of “offers”. Maybe there is a temporary way (snippet), for example ordinary sellers could be limited to 10 offers, and those who are verified to 30. If it is possible to help with such a snippet I would be very grateful to you guys.

  3. Ranking for users who create queries would also be a great feature.

Yes, adding sorting option for attributes in .hp-listing hp-listing–view-block will be greate

@DDV

  1. Sorry, there’s no simple code snippet for this, if you’re familiar with customizations or have a developer for custom work you can try using the hivepress/v1/forms/offer_make/errors to allow or disallow making offers based on the current vendor or request attributes.

  2. Thanks, we’ll consider this feature, it seems to be suggested here Add paid packages to requests - #9 by ihor

  3. We plan to add badges and similar features for users/vendors, either as the part of the core or as an extension.

@Nikolay If you mean adding custom sorting options to the Listings block we plan to add this feature, along with the custom attribute filters (currently this block has default filters and sorting options only).

Yes, that’s a suggestion, what would make limiting requests in the form of sold packages. That’s great. I’ve found a workaround so far:

  1. limited the requests to all users and vendors to 2 (for example), since I can’t split them up.
  2. I gave vendors who buy a PRO package the ability to submit more requests up to 10 (for example). Now everyone who has a PRO badge can make up to 10 requests.

I want to clarify, we are talking about limiting the responses to requests:

  1. limiting the response to the request for sellers, that this would be implemented in packages. For example I will create package #1 - 5 responses, package #2 - 10 responses, package #3 - 15 responses

It’s about limiting the requests themselves:

  1. limiting the queries for everyone, in the form of creating packages, e.g. package #1 - 5 queries, package #2 - 10 queries, etc.

And I don’t quite understand how queries work now:

  1. User creates a query

  2. Vendor responds to the request

  3. The user accepts the response (makes the payment immediately)

  4. Upon payment and crediting, the request disappears from the request page. After payment through a partner payment system, the status of the order should automatically move to “Processing” - right? Then the seller will be forced to contact the customer.

  5. The user’s profile doesn’t show the status of transactions on the request in any way, except for the mailing letters, this is functionally incorrect. The profile contains his request, without displaying the pending status (for example). The user doesn’t realize that he needs to wait for a response from the seller.

  6. After the request is fulfilled, by the seller, how can the user confirm this, so that the seller is credited? I don’t see any further development in the seller and customer profile other than to correspond further. How can the user confirm that the seller has fulfilled the request, and the service will then move the “Processing” status to “Completed” status. Maybe I have some kind of error, and does not output the opportunity to confirm the fulfillment of the request or dispute?

  7. Still think the button “Communicate with the seller” next to “Accept an offer” is just extremely necessary in the basic functionality of the topic, that before paying (even if it’s a secure payment) could discuss all the terms, meet or hold a deal. After that the “Seller’s offer” is accepted and the money is deducted.

Thank you, Ihor
With point:
6. Problem solved - there was an error with woocommerce pages.

Ihor one more thing, the problem on mobile device in seller profile table with hp-listings hp-block hp-table are not visible buttons which are on the right - ads, view, and other action buttons. Dates after statuses (done or other) are half hidden because there is not enough screen.

At the same time the same table on the request statuses and buttons in the profile, adapts to the mobile device completely.

If you use the Marketplace extension with Requests, it should work this way:

  1. User posts a request.
  2. Vendor makes an offer.
  3. User accepts it and pays, a new Order is created.
  4. The rest works like with paying for a listing, user/vendor can communicate via the order page, accept/reject the delivery, dispute order, etc. Also there’s a View Request button on the order page if checking the original requirements is needed.

So once the payment is made and the order is created, the request is hidden and linked from the order just for reference, then there’s a common order workflow.

Thanks for reporting the table issue, we’ll fix it as soon as possible.

Thats awesome , Ihor

Thank you :slight_smile:

Thx, Ihor - Now I’m convinced exactly how it should work.

Yes, I will very much look forward to a correction in the coming days. Thank you very much. Otherwise, sellers, very uncomfortable to work in a mobile device and rather discourages to use the service.
The users (customers) are fine with the table.

Thank you again for your work.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.