Bulk operations for order management

This sounds like a good improvement of the module. So of course your contribution will be more than welcome.

I have been receiving feature requests for support for other uc modules as well. So I am planning to reorganize the module, so it will come with several sub-modules each containing their own dependencies. So people do not have to install modules that they don't use.

So if you can write the patch as module with uc_views add uc_bulk_operations as dependencies that would be really great - if you already wrote the code inside of uc_views, then don't worry, just attach the patch and I will do the rearranging.

Thanks in advance - it is really great to get contributions :-D

I have only played around with taxonomy, not used them in a real project yet. So I would think of my self as a novice in that area. You sound like you have been investigating this, so I am very open to your suggestions.

can you explain in a little more details, how you were planning to use the taxonomy?

I like the way you want to split up the modules in to function related areas (management vs. marketing). But I think it might give troubles as to determine where table descriptions for views should be placed (hook_views_data()) . E.g. I have a feature request for supporting attributes. If that is to be split up into more modules, which one is then going to contain the table mappings?

This is not to say that we can't do it that way, I am just trying to figure out the pros and cons by thinking out loud.

Great. Thank you for the work. I will fit it into the source tree.

I finally had the time to work on this, and have committed your patch to cvs.

I decided to change the structure a little different from your way of doing it - so we now have a bulk_operations sub-module.

This is not the final restructure - but what was the easiest to do right away.

Thank you for your great work.

Yes, I intend to do some more restructuring, and I think the dependency to slide show, and also the much discussed use of db-views are candidates to go into separate sub-modules.

The reason for not splitting into order, and product modules right now, is that I want to keep it as simple as possible to upgrade the module for people using 6.2.x version. And then let everything that breaks backwards compatibility go into a 6.3.0 version.

In my mind the core table definitions (uc_orders and uc_order_products) could go into a base uc_views module (as today) and then let all the submodules depend on that.

The reason I like to keep at least uc_orders and uc_order_products together is that uc_orders need uc_order_products to make a join with node so there is a real dependency there that is not easy to work around.

Default views based on these definitions could still be split up the way you suggested. So I guess what I am coming to is something like:

uc_views
   L views (default handlers and core table defs)
   L uv_view_bulk_operations
       L views
   L uc_views_orders
       L views (default views and maybe handlers)
   L uc_views_order_products (dependency to slideshow)
       L views (default views)
   L uc_views_attributes (dependency to uc_attributes)
       L views (d efault views and definitions)
   L uc_views_cck (dependency to content)
       L views (dynamic joins for cck tables)

I am not so fond of having that views directory right underneath uc_views - it could get mixed up with the sub-modules for someone browsing the code. On the other hand it ensures that people who upgrade by copying the new release on top of the old one gets all their old view definitions deleted and replaced with the new ones. I am not sure if that is a 'service' we should provide - but I am pretty sure many would miss it if it just went into the release notes.

I am not done thinking yet but this is what I am favoring at the moment - your input is very welcome - it is great help having some one to discuss ideas with.
If you are interested I would also appreciate a co-maintainer.

Good luck with the training - I am afraid I didn't answer your question in a straight and obvious manner, but this is the closest I get at this moment :-(
I will be glad to try and help in any way I can though to solve this matter for you.

Hey guys - I was at Drupal Camp Colorado and attended the UC + Views session. A lot of the functionality that was demoed in that session (Endicia and UPS integration, bulk order printing and status updating etc etc) was really awesome and can't come soon enough for me (and I'm sure a lot of others) :-) Any idea when it's going to be deployed as a release so we can get our hands on it?

thanks ever so much

Jason

Hi Thill - thanks for the response. Any way the UPS Worldship export feature could be released as a separate UberCart module? So many online stores use UPS so this would be a really great and much-used feature.

thanks!

Jason

Thill - brilliant - thanks ever so much!!!!

I installed the uc_views_new patch but when i go to the view page (/admin/store/order_management) - the bulk operations buttons are blank and don't do anything? (see attached pic).

Any ideas??

Ignore last post - got it fixed! I edited the new order view and went into the Bulk Operations settings. Down there at the bottom were a load of (un)selected operations (print, update, export to WorldShip etc etc) which I checked and et voila - now I can batch print, batch update and batch export to WorldShip - thank you *SO* much guys - freaking *awesome*!!!!

Hi thill_,

I was intrigued by Jason's mention of your Endicia integration at the Drupal Camp Colorado presentation. Integration with Endicia is an important, but missing piece, for me. Would it be possible for you to post the code for your Endicia module/integration?

Cheers,
Ben

Hey thill_,

Thanks so much for the Endicia code! It works great. I really appreciate it.

The only thing I had to do was change the dependency on "uc_views_orders" to "uc_views_bulk_operations" (in the module's .info file) since that is what the module is called in the 6.x-3.x-dev version of Ubercart Views (which is the version that I'm using).

Quick question: I noticed that at the end of a batch Endicia can return a XML log file with the USPS confirmation number for each package that was shipped. Have you thought about a way to upload this file within Ubercart so that each order can be automatically updated with its tracking number? This way, customers could see the tracking number from within their Drupal account....

Thanks again,
Ben

Hey thill_,

Thanks again for your Endicia module. I've run into one snag: In the resulting Endicia XML file, the and tags are both blank... preventing me from specifying the postage rate that should be applied to the Endicia label.

How do you specify the Package Type and Mail Class from within Ubercart? Am I missing a module that works in complement to the Endicia module?

Thanks so much,
Ben

Hi madsph,

I hope all is well. I've been working with the 6.x-3.x-dev branch (it's working great!) and I just wanted to voice my support for committing thill_'s contributions (Endicia export, UPS XML, etc.) to the Ubercart Views module. His contributions are very useful, much needed, and would make great sub-modules.

Thanks,
Ben

I agree, thill_ makes some fantastic additions to this project and I would like to include them - but he said something about creating his own project, so I have been uneasy about adding his work for this project - I don't want him to think that I am stealing it.

What I really like to do is to grant him (you - if you are reading this thill_ :-) ) commit rights to uc_views so he can take charge of his work and decide where it goes.

Hi - I have Thill's Bulk Order operations module (above) installed. It's been working really nicely - but I just upgraded from UberCart RC7 to UberCart 2.0 and it's now broken. When I surf to the page (/admin/store/order_management) - it's blank. I get this error in the logs:

[Mon Oct 26 17:39:12 2009] [error] PHP Fatal error: Cannot access empty property in mysite\sites\all\modules\ubercart\uc_product\views\uc_product_handler_field_price.inc on line 63, referer: http://localhost/mystore/admin/build/views/edit/orders
[Mon Oct 26 17:39:23 2009] [error] PHP Fatal error: Cannot access empty property in mysite\sites\all\modules\ubercart\uc_product\views\uc_product_handler_field_price.inc on line 63, referer: http://localhost/mystore/admin/build/views

I raised this error on the main UberCart forum (http://www.ubercart.org/forum/support/13625/fatal_error_when_upgrading_r...) and Lyle told me to clear my Views Cache. That fixed the problem of the homepage (which uses views to display featured products) but doesn't seem to have fixed my Order Management view at all.

And when I edit the "order management" view and click "preview" I get a dialog box with this error message:

An error occurred at /admin/build/views/ajax/preview/orders

All the other views preview just fine though.

Any ideas?

cheers

Jason

Your problem is related to these issues:
#614032: Views with Order total field blank in UC2.0
#611060: Fatal Error when upgrading from RC7 to UC2.0
#611044: Fatal error: Unsupported operand types in .../uc_order.module on line 1459

Essentially this is a problem with the Ubercart project forgetting to namespace its hooks which has now lead to a function name clash with the Date module.
It is very unfortunate but as I understand it is being handled with high priority.

How ironic I'm posting to a two-month old thread the day after it's closed...

Thank you thill for making the Endicia module available - definitely awesome. I just installed it, however, the XML it exports doesn't include any info beyond the order total, weight and email. The most important information - shipping info - doesn't get included in the XML file. Any ideas?

Thanks,
Jugney

Hi all,

Curious. When I tried it today, the XML file included everything, but Endicia for Mac didn't import the email address.

Endicia Mac support said the XML tag needs to be ToEMail and not ToEmail. I'll test tomorrow to see if that makes a difference.

Any other thoughts?

Jugney

My turn to bring this back to life!

I've setup the uc_xml_ups module you posted (thank you thank you thank you) and views_uc, views_bulk_operations. I've then enabled the "orders" view, cloned it, and setup the formatting to use "views bulk operation" and then "Export to Worldship" as the selected operation.

Problem is, the resulting XML file is pretty much empty. The only info that gets filled in is the Package type, # of packages, and a weight of 0 which is wrong.

Was I wrong to enable the above posted module, has this already been implemented officially into a more all-encompassing module like uc views? If I'm on the right track, any suggestion what to do so that my view is populated properly?

Thil - any advice on using this module? All data appears in the view just fine, but when I "confirm" the export I am given an XML file that is missing almost all data.

For example, if I export 20 orders, 5 or 6 will have customer information in them, the remaining 14-15 orders in the XML file have no data -- just the XML structure. I cannot find anything in common with the missing orders, like anonymous vs authenticated users.