Vendor order listing limitation?

-- url of the page with the problem -- : local dev MAMP
-- HikaMarket version -- : 1.4.1

Hi Jerome,

Need to bother again... but first you should go to sleep this late holiday night - this isn't urgent...

Prolog:
I can't help it, I'm having and using a few more order statuses than default.
For a number of reasons, my vendors must be informed of, and have an insight into orders only from a certain order status on.

Question:
How can I limit the display of orders in the frontend order listing for vendors depending on order status, meaning show orders with a certain status while not showing the others? Again, if it helps, the first few statuses must not show, while the last bunch of statuses shall show.

Been looking through bunches of view and helper PHP's already, but guess I'm too dumb to see it.

Thanks! And good night...

Sorry Jerome,

But I just thought I had THE idea: "Use ACL on order statuses to block them from being seen!"

So, I went to edit the "created" order status and set ACL to only admins and super-users. Nope, "created" orders still in vendor's order listing view in frontend and accessible.
ACL to "None". No change, still the same.
I also unpublished the status. No change, still the same.

Just FYI, check on the Shop side: All the same as well, created orders listed for customer, emails on creation, etc.

And all the same for different order statuses as well.

Duh?! What am I forgetting/overlooking? Why am I expecting that an order status, technically a category, doesn't show anymore if I both unpublished it and set ACL to none? Seen it working with other category types, am actually using the feature for certain product categories.

Attached what might not be telling much more, but anyway.

Thanks for a nudge for where I'm wrong, if so.

Sounds good what you're saying. You're the expert, but guess your idea makes very good sense.

Every case is different, so for as long as flexibility remains, like e.g. adding order statuses (or maybe even removing/skipping/unpublishing one or more from the core), it should be good. See, not every Market is like an Etsy. My case, where I need more steps and keep vendors and customers separate until late in the order process, might be extreme, but think brokerage where you simply don't want customer and vendor to know each other or even communicate before a "secure" stage is reached in the transaction. Well, I'm sure you know.

I was looking at order status ACL as a workaround, fearing it to backfire somewhere on the Shop side, e.g. order statuses become useless or even blocked on the Shop side and the system coming to a screeching halt, eventually. While it might still a valid tool, let's keep an eye on possible side effects...
Next thing, maybe some "if" in PHP. I'm not good with that, but might need to try (or cry for help) if no other way.
Also found a way to hide orders with certain statuses per CSS, but you and I are not the only ones having a driver's license for Firebug or similar, so it's too unsafe, making it a no-no.

After all, your "official" solution looks best, and will be best, I'm sure. Usual question: when? Maybe I won't need an "if" condition, or long testing all across the site after applying ACL. Let me know if you need a guinea pig. Nope, not on a live site.

Thanks & cheers!

Hi retour,

And thanks for digging further into this. I'll see when I get to it (was just dealing with some other stuff, as you can tell from my most recent post ), but probably soon... I usually can't wait trying, lol...

Me again.

Uhm, frankly, I have difficulties getting my head around what you said. You mean something like a "hard-coded filter" for what order statuses are being displayed in the listing? Hmm, would work (for me and some more) as a one-time setup, but can't be more than an interim solution, no?

You have the ACL for what a vendor can edit in an order, that's great. But IMHO there's got to be a pre-selection (ok, call it filter) for which order statuses he can access, even see.

Example: In the custom fields backend you have the "Display" fieldset with a bank of switches. I think that could work - would be nice, actually - in order statuses as well regarding vendor:
Vendor order listing: yes/no
Vendor order editing: yes/no

Or so. Well, just my 2 cents...

Ok, I'll still try to figure something out with order_status... not sure what'll come out, though, if any...

One-line addendum, speaking about ACL:
What about the order statuses showing up in the ACL (like product details), except the checkboxes enabling their display in the vendor order listing or not? Would keep it all together, nice and tidy?
Edit: And should keep the extra code short and sweet, or? Just some lines of "if's", no?

Jerome wrote: ... a single "if" won't be enough.

Well well, anything that direction wasn't meant too serious from my side...

After initially opposing the "vendor group" approach (hard to manage?) when reading your post, on second thought I started liking it more and more.
Let's face it, the vast majority of admins treats their vendors all equally. And few exceptions among vendors, meaning moving some of them to a different group, can be dealt with. So, yes, if I were able to say, "vendor group A can see/access only order statuses 4 and 5", while "vendor group B can see/access all order statuses" (or none at all, for that matter - and whatever my default will be), that should do just fine. Along with the already existing possibility of applying a default group to vendors upon their registration, and ACL for what they can actually edit, I think this would make good sense and be a viable solution! If that's what you mean and I got you right... and not wanting to think of what it would take for implementation...

Hi again,

Oh, so maybe I did get you wrong regarding "vendor groups".

Anyway, and as indicated before, making it part of the ACL sounds ideal to me. If the individual order statuses showed up in HikaMarket ACL and admin could use the checkboxes there to make each one visible/accessible for vendors or not - perfect!

Not sure if I understand your note on ACL display and form input limitation, but I guess we'll see in next release then?

Oh yes, if you want to get all that under one roof, I can imagine it being complex and getting complicated! It might get pretty complicated for the user (admin) as well unless you i.e. wrapped it into some "logical" step-by-step process, or so. Some ideas are coming to mind, but you might already have some as well...