Posted by DigitalFrontier... on May 21, 2009 at 5:57pm
4 followers
| Project: | Package Tracking |
| Version: | 5.x-1.0 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hi TR,
I have a question similar to #448494: Tracking field doesn't show up in customer order summary but for 5.x-1.0. Running D5.11. If logged in as admin to check tracking for a user's order, I navigate to /user/xxx/orders/track and I don't get the additional tracking field in the order history despite having the shipping method installed and having entered a tracking number and choosing a carrier.
Just wondering if you have any idea what I might be doing wrong here.
This is for http://idstronghold.com .
Thanks,
Stephen
Comments
#1
Oh, and this is with UC 1.5 with both Shipping and Shipping Quotes modules turned on.
#2
The tracking column should show up on the table in the user order history page at user/#/orders. If it doesn't then the code isn't being run. Check your system table to make sure the weight column for the uc_tracking row holds a higher number than the weight column for the uc_order row. Flush your caches. You're not also running uc_reorder are you?
#3
Hi TR,
No, not running uc_reorder. Will do as you suggest and hopefully report success. ;-)
Thanks,
Stephen
#4
TR,
I did as you suggest and the column DID show up for user/1 when logged in as user/1, thus I'm assuming that it's showing up for other users (now at least). But as user/1 admin, I should be able to view the tracking info for other users as well. I can tell that the tracking code is not being called when I look at user/1266/orders when logged in as user/1 because the table styling is not even the same (unthemed) so it must be calling the old table theme code.
Seems to me this is perhaps due to checking against $order->uid instead of $user->uid or access permissions to choose whether or not to build the tracking table.
[EDIT]
Guess that's not it since it IS checking against $user->uid....
#5
Should these lines:
'path' => 'user/'. $user->uid .'/orders',actually read:
'path' => 'user/'. arg(1) .'/orders',so that user/1 can look at user/1266's tracking info?
#6
No, this:
Line 77
'access' => user_access('view all orders') || $user->uid == arg(1),should be:
'access' => user_access('view all orders') || $user->uid == arg(1) || $user->uid == 1,I think that's it. Will test and let you know.
#7
Realized user_access negates my last thoughts. Went back to original suggestion and it works. It seems use of $user->uid in the paths, etc. isn't appropriate since an admin might be checking on the order history pages of other users.
This patch replaces $user->uid with arg(1) in appropriate places that seems to work on my end.
#8
http://drupal.org/project/uc_reorder
Was working fine till I installed this module.
The button has vanished!
Uninstall and it's OK again.
Running latest update of version 5.
PS What happens when you have multiple tracking numbers? (We could have up to 4 per order) we can enter them separated by spaces.
Thanks
Steve
#9
hotcom: Please don't hijack threads. Your issue has nothing to do with the original post in this thread - if you are having a different problem then you should start a new thread, not re-title an existing thread.
To answer your issue briefly: uc_reorder and uc_tracking can't work at the same time. This is stated on the project page. Multiple tracking numbers are shown properly when you ship multiple packages for an order.
DigitalFrontiersMedia: I haven't forgotten your issue, just haven't had time to address it yet. But I'm curious how the admin navigates to user/#/orders rather than admin/store/orders to check on user orders. My thinking is instead of changing permissions perhaps I should add the tracking numbers to admin/store/orders as well ...
#10
Hi TR,
No worries on delay.
The patch I included doesn't really change any permissions. It just changes the arguments supplied for the url so that instead of the currently logged in user's id, it uses the uid of the order's customer.
Here's an example of how a store owner might navigate and run into the bug:
1. Check orders at admin/store/orders/view
2. Click on an order to view it.
3. Think to one's self, "let's look at information about this customer and other orders by him/her", then click on the customer number link in the "Customer info" pane. This takes you to their user page.
4. Read info about user then click on their Orders link to view order history (user/#/orders).
As written, the module will display order history but will NOT show the tracking info since instead of displaying tracking info for user 1766 or something, it's showing the tracking info for user 1 (or trying to at least for whomever you're logged in as).
The patch basically institutes the suggestion in comment #5 above.
I'm not sure how often this workflow would occur, but it seemed like a natural investigative path for customers & order history to me.
Hope this helps.
#11
I looked into this issue and created version 5.x-1.1 to make the module work as requested. Re-classified the issue as a "feature request" because after working on it I believe that's really what it is - an additional feature for the admin user. The fix was to patch the module as in #7, but also to move the menu callback out of the $may_cache block. It failed to work properly in the $may_cache block because of how Drupal 5 constructs and caches menu paths.
#12
Cool. I hadn't thought about cached menu paths. Thanks, TR!
#13
Automatically closed -- issue fixed for 2 weeks with no activity.