It might be nice to add a column to the payment history page to view the different gateways used to purchase.
Perhaps we could add a screen option to toggle what columns are enabled to make the this more feasible due to screen space.
@easydigitaldownloads/core-devs thoughts?
I'm not too sure how useful that would be. Why would you want to be able to
quickly see that information all of the time?
I personally don't see the need for it.
Yeah I agree with Sean, if there's a usecase for it it'd be trivial to do, but I'm not sure why the avg user would gain from being able to do that. The one thing I could see is a filter above the list table to filter by gateways, which might be useful if you have a bug in the gateways, but frankly I think that would be clutter itself. Perhaps that could be implemented as a url-only filter (no UI)
I agree with @SDavisMedia and @chriscct7 - not seeing the gain here personally. If a user _really_ wants it, it can be added in simply via filters.
I personally had numerous cases where I wanted a way to view just the payments that came through a specific gateway, so I think it's it a great feature.
I do not think, however, that it needs to be a column in payment history. I would, instead, like to see it available as a drop down filter above the table.
I think available dropdown is the way to go, like filtering a category on the Post List Table. I'll update the issue to reflect this.
Note, when this is done, it should be done in a way that also facilitates additional filters being added by add-ons, like this https://github.com/easydigitaldownloads/EDD-Software-Licensing/issues/984
@pippinsplugins Ok, I'm not 100% sure I'm thinking the same way you are. I've got a partial implementation of a function that uses restrict_manage_posts to add a dropdown for filtering by payment type. Seems to be basically what you're looking for, but i'm not sure what you mean by 'facilitates additional filters' in this context. Wouldn't addons just use the same restrict_manage_posts filter I'm using?
Just realized we're already doing that. I should be modifying the existing edd_add_download_filters function rather than adding a new one.
I'd like to see it added in the same way that the date filters are added.
Oops, not edd_add_download_filters, wrong post type
The date filter is a search, not a filter. I assumed you wanted something akin to the category and tag filters in the download post type. Are you saying you want the filter to be added to the existing payment search form?
@ghost1227 I'd like a dropdown but I want it placed inline with the date filters.

@pippinsplugins Something like this then? That filter bar is getting super crowded.
I should note, if I'm on the right track, it looks like you want a new action added in the edd-payment-filters div just before the Apply button. Sound right?
Yep, looks right to me.
Can we put an action in here?
I wanted to drop one of these in for SL 'renwals and upgardes' but there wasn't a way to add it BEFORE the Apply button.
@cklosowski yea, that's what I was thinking
First pass at actually adding the field and associated action. No search logic yet, I'm still trying to sort out the right way to adjust the payment query using the EDD_Payment_Query class to filter by gateway. @cklosowski Let me know if that action is where you want it.
@ghost1227 EDD_Payment_Query supports the standard meta_query of WP_Query :)
I figured as much, just had to track down the meta key used for gateway :P
@pippinsplugins filter now works, but I'm having trouble getting it to update counts
You will also have to pass it to the edd_count_payments() function
@pippinsplugins I knew that. Was having issues with the $wpdb code. Never was great at direct queries. Got it though!
@ghost1227 could we fix the slight misalignment?

Besides that, this appears to work great!
@pippinsplugins How would you like that done? It's technically not a misalignment in the usual sense... dropdowns take more space natively than other fields, so the new dropdown is forcing the filter bar to grow to fit its contents.
Perhaps a negative top margin?
@SDavisMedia would have better methods.
Taking a look now. Standby.
@ghost1227 as you mentioned, all of the elements won't be the same height unless we force them. They're just different by default. Slippery slope if we start controlling that all around the dashboard.
So just give the text input fields vertical-align: middle; to get everything vertically centered.

@SDavisMedia Makes sense to me!
@pippinsplugins See if that's better. (submit fail... apparently didn't actually hit the comment button)
@ghost1227 The select field is not an input, so your last commit removed the alignment.
@pippinsplugins not sure what you mean... the last two commits together should be correct. Are they not aligned for you?
@pippinsplugins @SDavisMedia It's aligning correctly for me...
I don't see any change in the alignment. Still looks like my screenshot
above.
On Fri, Feb 24, 2017 at 1:16 PM, Sean Davis notifications@github.com
wrote:
@pippinsplugins https://github.com/pippinsplugins not sure what you
mean... the last two commits should be correct. Are they not aligned for
you?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/easydigitaldownloads/easy-digital-downloads/issues/5223#issuecomment-282379066,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA_HfVtCDSiEuRetZNwvIjkN5f13mhjnks5rfyyCgaJpZM4K14jV
.
@pippinsplugins something has to be wrong on your end. You mentioned that the select field is not an input. That's fine because WP admin CSS already vertically aligns select menus to the middle. That's why I told Dan to just target the text elements.
Perhaps something else is interfering. Does your CSS for the select menu look different than this?

I had script debug disabled. All good here :D
Let's get some unit tests added to this before we merge it in, otherwise it's good to go.
What do you want tested? Just the new gateway payment query arg?
@ghost1227 I want unit tests that query payments for specific gateways and then check the results.
Let's move this up in priority. No need to let it sit so long.
All working well here. I'm going to merge now.
Most helpful comment
I think available dropdown is the way to go, like filtering a category on the Post List Table. I'll update the issue to reflect this.