Ubercart

Is this related to the Ubercart Views contrib? http://www.ubercart.org/contrib/9429

I helped / watched Sammy work on this at the Drupalcon code sprint and have installed http://www.ubercart.org/contrib/9429, so I'm pretty sure I understand the difference. Sammy's patch creates a new primary view type (think nodes, users, comments, accesslog and now orders) for orders. Madsph's patch contains some useful default views and tells views how to reference some of the order data, but does not seem to create a primary view type for orders like Sammy's

Andy hit the spot with his comment. My stuff is making uc_orders a base table for views. I'll also be making, the aboveposted uc_views, the previous uc_products views support and my stuff consistent.

The aim is to produce a solid Views 2 integration for Ubercart.

Since some people are watching this thread now i'd like to know if we should put all views stuff into the uc_reports module. It has the same dependencies we'll need for views support to work for orders and it makes sense to combine them since people wanting reports will most likely want views stuff.

So... do we put views code into uc_reports or shall we keep them separate?

Awesome! This will be a big deal I think for a lot of the UC project. (cha0s and I talked about exposing the File Downloads uc_file module to views and Taxonomy as well... fun stuff.)

Sammy,
I see two separate things here. One is the orders and products table definitions for views and the other is the collection of default views madsph created. I would love to see the orders and products table definitions for views make it into core for 2.0 so they would be in uc_orders/views and uc_products/views (which already exists). I think the collection of default views should be an independent module but should only include exported views, and not views table definitions.

So: views table definitions with their respective modules in core; the reports module containing exported views which fit the definition of reports; and a "standard views" modules as a catchall for other popular views exports.

I hope this makes some sense. The terminology for views gets a little tricky.

I agree. It would be more convenient to separate definitions and default views. I always hated the idea that people had to install my views, if all they wanted was the definitions.

I am right now working on some definitions including some field handlers and filter handlers for the next release of uc_views. I think we should find a path to merge these changes into your module if you are interested.

madsph

Not sure of a final solution, but having a definition module that maybe resided in a suite of modules might be nice until we can work it into core. Given the current pace of Views integration development and the near release status of 2.0, I'd wanna hold off on putting it into core. We can make releases more quickly while it's in contrib space and make sure people know where to find the code. I'd stay away from patching it into the reports module. If I'm not mistaken, we'd ultimately want to use the automatic Views include file system for these... Lyle knows more about that than I do.

'Patching into report module' meant we utilize the view include stuff. What I was asking was whether we place the defs and default views under the uc_reports directory. Anyway... enough about that.

I've tested what I had then integrated it all with the uc_views contrib. You'll find a patch attached for that. People can play with it in the meantime and get a feel for it.

Ryan/Andy: You two are conflicting in what you have written above. What's the decision on where this stuff goes? As far as definitions go there is another option: Add the current definitions to core AND create a uc_views_definitions module to speedily make new ones available.

It looks like your patch doesn't include the views_handler_field_order_id.inc file. It also won't apply to the 6.x-1.1 version of uc_views.

You don't need to use t() on the schema descriptions, since they are already using it in hook_schema(). UC_PAYER_PREFIX and UC_RECIPIENT_PREFIX aren't translatable, either, but I don't really think they are necessary. uc_views has already added the order fields it was missing, so that part of your patch will have to merge with those additions.

I can't tell which is better yet to use relationships or field handlers for zones and countries. Someone will have to do benchmarks to see if the difference is significant. My suspicion is that it doesn't matter.

This is a great step in the right direction, though. I really appreciate you making this patch.

Thanks for looking at the crappy patch Lyle. I didn't look at the d.o page. Grrrrr!

I'll see what, if anything, I can add to the 1.1 version. Forgot that schema does the t()'ing. Thanks for the reminder.

Re: relationships vs field handlers... Relationships are only used to pull in a different base table (and any joins it results in) to the view. I don't see countries and zones being a view base myself. Please correct me if i'm wrong.

Will roll up another patch (with the handler this time if it's needed - sorry about that) tonight.

Here is a working (I hope) patch against uc_views 1.0 with the t() removed on the schema bits. This one is for you Andy!

This looks really good!

Thank you for the patch.

I am a bit hung up at work these days, so please forgive me if I am a bit slow to work these changes into uc_views.

You're welcome madsph! I've rolled the patch against 1.1 and you'll find it attached. I think we might need to make the uc_orders <-> uc_countries and uc_orders <-> uc_zones joins into a view once everyone is happy with what's done so far. It's a really cool idea to use views. I love what you've done so far madsph!

For those that want a quick list of what this patch provides...

• Adds orders to views as a base table. This means you can base your views on orders instead of on products.
• Allows orders to join up to the user that ordered.
• Displays all order fields from the uc_orders table.
• Can optionally link the order ID to the order admin screen.
• Can have order id as an argument.
• Can show all country and zone fields (e.g two letter country codes).
• Adds primary_email field and render it as a mailto: link
• Uses field descriptions from the schema subsystem to reduce developer efforts in future.

Enjoy the patch (I hope )

Thanks again for the patch!

I am almost done applying it. I think the views_handler_field_order_id.inc is missing from the patches, can you submit that also, then I will give it some testing and commit to CVS.

Thanks
madsph

Developing a view that allows access to the orders table -- this is great! Is the issue noted by madsph relevant? And will I be able to access the user-filled product attributes by applying this?

st00pid question time -- how do I apply this?

I've applied patches with .diff extensions; is this the same thing, or do I drop it into a folder somewhere?

I figured it out -- same way other patches are applied.

I'm hoping to start testing both this and your module -- is this element missing, or all set now?

It is still missing.

I have pm'ed sammys, but no answer yet. I guess he must be on holiday or something.
I am still a bit hung up at work, but if I find the time, I will try and write it my self.

I have now written my own version of the missing field handler for order_ids, and made sammys patch available through a new 2.0 release for uc_views.

The reason I have chosen to label it 2.0 rather than 1.2 is that it breaks backwards compatibility with views from the 1.1 release containing order fields, due to the fact that the order table is now a base table.

uc_views can work coexist with sammy's patch ?

Downloading and playing with it now.

along with the missing .inc, and that the 2.0 is now a "complete" solution (until the next upgrade/update). madsph, correct me if I'm wrong...

No need to correct you - you are absolutely right

Thanks for filling that part in madsph. I didn't realise I could get pms in here so didn't check. Sorry about the missing file. Great news that it's all rolled up.

Shall we also add in the attachments stuff from contrib? http://www.ubercart.org/contrib/3960

That sounds like an interesting thought. I will contact the author of that contrib and hear what he thinks.