The problem

When editing orders, it is possible to select addresses from the address book (as requested in #396342: addresses in admin orders interface). Currently there are some issues with the zone field. While selecting an address from the address book is possible, the zone value is not correctly updated when the country from the selected address is different from the country currently active on the form. Also, when copying over an address from one address pane to the other address pane, the zone value is not correctly taken over when the currently active countries in the two address panes differ.

The proposed solution

While checkout in Ubercart has been improved on selecting and copying addresses, the order administration uses the same javascript as in Ubercart 6.x-2.x. This makes the order administration less flexible, as I have plans to add support for extra address fields in the future. If the order administration operates the way it does now, the support of extra address fields will be limited to only a few address fields.
The delivery and billing address form on the checkout page makes use of the #ajax property, with which a Drupal form can be updated by a javascript event. The nice thing about it, is that Drupal updates the form by using the same form API, so issues like "An illegal choice has been detected" can be avoided. The order administration form doesn't use this strategy: it just replaces form elements with javascript without going through the Drupal Form API.
I'd like to have the order administration form work in a similar way as the checkout form.

Want to help?

This issue is here for volunteers to be picked up. Assign yourself to the issue first if you want to work on this one. This issue needs to be fixed prior to the release of 7.x-1.0-alpha1.

Files: 
CommentFileSizeAuthor
#39 uc-addresses-order-admin-feature-1424038-39.patch9.47 KBMegaChriz
PASSED: [[SimpleTest]]: [MySQL] 5,232 pass(es).
[ View ]
#37 uc-addresses-order-admin-feature-1424038-37.patch7.64 KBMegaChriz
FAILED: [[SimpleTest]]: [MySQL] 5,222 pass(es), 12 fail(s), and 0 exception(s).
[ View ]
#37 1424038-rules-ui-button.png2.72 KBMegaChriz
#37 1424038-order-edit-37.png25.46 KBMegaChriz
#33 uc-addresses-order-admin-feature-1424038-33.patch8.41 KBMegaChriz
PASSED: [[SimpleTest]]: [MySQL] 2,233 pass(es).
[ View ]
#33 images.zip2.46 KBMegaChriz
#32 d-site-install.sh_.txt3.78 KBMichael-Inet
#29 uc-addresses-order-admin-feature-1424038-29.patch20.48 KBMegaChriz
PASSED: [[SimpleTest]]: [MySQL] 2,174 pass(es).
[ View ]
#28 uc-addresses-order-admin-feature-1424038-28.patch18.17 KBMegaChriz
PASSED: [[SimpleTest]]: [MySQL] 2,174 pass(es).
[ View ]
#28 images.zip2.46 KBMegaChriz
#26 uc-addresses-order-admin-feature-1424038-26.patch18.47 KBMegaChriz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch uc-addresses-order-admin-feature-1424038-26.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#17 uc-addresses-order-form-1424038-17.patch8.49 KBMegaChriz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch uc-addresses-order-form-1424038-17.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#17 1424038-wide-address-panes.png98.25 KBMegaChriz
#11 uc-addresses-order-form-1424038-11.patch7.18 KBMegaChriz
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch uc-addresses-order-form-1424038-11.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#9 patchfile.patch5.48 KBmesch
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch patchfile_0.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

Michael-Inet’s picture

MegaChriz,

As you said you don't have the time, we'll sponsor this to be fixed by another developer, but, can you bullet point out exactly what you want done?

My first stab at stripping out deliverables:

- zone value is correctly updated when
- - when the country from the selected address is different from the country currently active on the form
- - copying over an address from one address pane to the other address pane

- order administration form to use #ajax properties (who's order admin is this?)

Please add system paths for clarity.

Best,
Sam

MegaChriz’s picture

The path the address form is located is at
admin/store/orders/[order_id]/edit
where [order_id] is the ID of the order.

The file uc_addresses.ubercart.inc currently includes the code for generating the delivery/billing checkout panes and the ship_to/bill_to order panes. Ubercart Addresses has overridden the order panes by implementing hook_uc_order_pane_alter(). This hook implementation can be found in the uc_addresses.module file.

The address book select field is currently loaded with javascript as a separate form, thus it doesn't appear in the order pane callback uc_addresses_order_pane_address(). The original address book form uc_order_address_book_form() is defined in uc_order/uc_order.admin.inc. This form is altered by Ubercart Addresses in uc_addresses_form_uc_order_address_book_form_alter() in uc_addresses.module. Ubercart Addresses replaces the selectable addresses (that come from previous orders) by addresses from the address book.

The address book form should probably become part of the order pane callback uc_addresses_order_pane_address() just as is the case with the checkout pane callback uc_addresses_checkout_pane_address(). Parts of the form should be updated by the form API by using the #ajax property on the address book select field and the copy address checkbox.

I hope this information helps. If there are still some things unclear, feel free to ask.

Michael-Inet’s picture

Category:bug» task
Status:Needs review» Active
Issue tags:-bounty

Edit (3/31/12): Bonus has been canceled by client :(

$150 Bonus for fixing uc_addresses, Order admin
http://groups.drupal.org/node/207923
http://drupal.org/node/1430198

Hello Drupallers,

We're offering a bonus to the first person that can submit a successful quick fix patch(s) for this module:

Module: Ubercart Addresses
http://drupal.org/project/uc_addresses

Issue: Order administration feature
http://drupal.org/node/1424038

Bonus: $150
Deadline: Feb. 13, 2012

Please submit your patch to the issue queue and I will do the testing/QA. Once accepted by MegaChriz (module owner), we'll PayPal you the bonus. After the deadline, we'll pay half, but I'll be working on it then as well...

Please add any module specific questions to the issue queue.

Best Regards,

Sam

PS: There are two others we are currently bonus-ing for uc_addresses, and if you can do all three, the total bonus will be bumped to $300.

Delivery information does not display in checkout
http://drupal.org/node/1421720
Bonus: $60
Deadline: Feb. 13, 2012

Ubercart Addresses user tokens
http://drupal.org/node/1424032
Bonus: $25
Deadline: Feb. 13, 2012

Jaypan’s picture

I worked on this and tied it into the #ajax system, and while the #ajax properly fires, and I can see that the new address is properly loaded, something in the definition for the element type of 'uc_addresses_address' refuses to load any definition other than the one originally supplied with the form, effectively killing any possible #ajax functionality.

Edit: to add to that, the default address is set in uc_addresses.ubercart.inc in uc_addresses_order_pane_address(). It is set here:

<?php
      $form
[$uc_type]['#uc_addresses_address'] = $address;
?>

No matter what value is set for $address in this form, it always shows the original form definition. For example, I can put:

<?php
if(isset($form_state['values']['ajax_submitted_address']))
{
 
// The address loaded from the address selected in the form elements I have created
 
$address = uc_addresses_address_load($form_state['values']['ajax_submitted_address'], $order->uid);
}
else
{
 
// The originally supplied address
 
$address = $order->uc_addresses[$type];
}
$form[$uc_type]['#uc_addresses_address'] = $address;
?>

The above code should load the default address on page load, and on #ajax submission, will load the address provided in $form_state['values']['ajax_submitted_address']. I have confirmed that in the #ajax submission, the address is properly loaded, but when form is regenerated and sent back to the page to be inserted, it always shows the original address, no matter what address was selected, and even though I have confirmed that the proper address has been loaded.

So I think it's a bug in the 'uc_addresses_address' form element, but I've reached my time limit on this and will be leaving it at this. But maybe this can help someone else if they try to fix this problem.

MegaChriz’s picture

But on the checkout page (with uc_quote module disabled, see #1421720: [$150 Bounty] Delivery information does not display in checkout) it's working with #ajax.

Michael-Inet’s picture

Title:Order administration feature» [$150 Bounty] Order administration feature
Assigned:Unassigned» Michael-Inet
Issue tags:+bounty

Deadline has been removed on bonus.

mesch’s picture

Category:task» bug

I've run into the same issue as Jay M. I can fetch the user's address book and create the panes with any of those addresses, but it does not seem to want to update via ajax. I can't justify digging through more code to fix this further for this bounty amount, and I don't have the available spare time at the moment.

Re: copying one pane to another, what about just disabling one of the panes (ala the checkout form) and doing the order updating (including copying of addresses among types) in the 'edit-process' op?

Re: the existing javascript, it wasn't working on my fresh drupal7/U3 instance.

MegaChriz’s picture

@MEsch, can you post (as a patch) what you got so far? I may be able better to track down the issue you ran into better in this case. On the checkout form, applying addresses from the address book works nicely, so I don't understand why yet this doesn't work in other forms.

I suppose you have adjusted uc_addresses_select_addresses() a little? This function now operates the "old way" when the context is "order_form", thus with JSON code as the key of each address. It should use address ID's when the address book select field is part of the order form itself.

This (uc_addresses.module, ± line 1111)

<?php
switch ($context) {
  case
'order_form':
 
$key = drupal_json_encode($address->getRawFieldData());
    break;
  default:
   
$key = $address->getId();
    break;
}
?>

should be replaced by this:

<?php
$key
= $address->getId();
?>

when implementing this feature as described.

mesch’s picture

StatusFileSize
new5.48 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch patchfile_0.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Patch attached.

To be honest it was unclear what the best method of obtaining the addresses was. I tried multiple different ways and neither of them solved the issue. I did notice the context issue, and I decided to use "uc_addresses_get_select_addresses" instead. I also tried the "loadAddress" class method directly, as well as Jay M.'s approach. All of them worked in populating the initial form.

I briefly checked out the classes, and there seems to be lots happening there; I wonder if the addresses need to be loaded in a very specific way in order for the uc_addresses_address form element to be updateable.

The patch doesn't deal w/ saving the changes... I stopped at the ajax roadblock.

MegaChriz’s picture

Thanks for posting the patch (sorry for my late reaction).

I had assumed that the hint

I'd like to have the order administration form work in a similar way as the checkout form.

would have been enough to know the checkout form already does the trick, and with the uc_addresses_address element (which I should document in the developer's guide). At the other hand, I know very little about how it exactly works on checkout. Most of the working mechanism is copied from Ubercart and some Ubercart code is still involved in the process. That fact makes it harder to fix this issue. But because it works at checkout, it should be possible to work elsewhere too.

I'll take a look at your code and see where exactly you "hit the wall".

MegaChriz’s picture

Status:Active» Needs work
StatusFileSize
new7.18 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch uc-addresses-order-form-1424038-11.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

I have take a look at the patch posted in #9 and I see a lot of wrappers in there which make it confusing for me what exactly happens there. There are not that much wrappers at the checkout form. I suppose it is used as attempts to fix the problem.

I have also made an attempt or at least a start to implement this. I took uc_addresses_checkout_pane_address() as an example as that is working completely. At first, I noticed the same issue as Jay Matwichuk and MEsch, that the address never did update. But when I added the following:

<?php
$form
[$pane] = array(
 
'#tree' => TRUE,
);
?>

things began slowly sort of working. That piece of code made sure the field "select_address" was named "delivery[select_address]" in the form HTML instead of just "select_address", which is harder to track down because we deal with two address forms on one page (delivery and billing). I've also replaced $uc_type by $pane for consistency (that's what the implementation for checkout uses).

The attached patch is capable of updating the address form when selecting an address from the dropdown. To concentrate at one piece at a time, I left out the functionality for copying an address from one pane to the other for now. Unfortunately, there are still some things that aren't working:

  • In some cases, the zone field is not correctly updated when changing the country, don't know yet why.
  • When just saving the form, I'll get the error: "Fatal error: Nesting level too deep - recursive dependency? in /Websites/drupal/drupalsites/drupal7/sites/all/modules/contrib/ubercart/uc_order/uc_order.admin.inc on line 1065". I saw an error like this somewhere in the Ubercart issue queue too, thus this could be a bug in Ubercart.

I think the changes in the patch gets us closer to the solution, but we aren't there yet.

MegaChriz’s picture

I've examined two of the problems noted #11.

The "Nesting level too deep" error

The "Nesting level too deep" error is caused in the uc_order module: it tries to compare the uc_addresses array from two order objects. In the $order->uc_addresses array live two UcAddressesAddress objects and because an UcAddressesAddress object is connected with an UcAddressesAddressBook object, there is some cross referrencing which is causing the "Nesting level too deep" error.

Zone field issues

For the issues with the zone field, I've found out that when the address form is updated via ajax, the address form element is processed twice (I've tested this with a single address form). This causes the construction of a new address object with an other ID, while it would work for us at best if the form API just takes the address object from the (form) cache. The address ID is used in the zone wrapper element to allow a form to have multiple address forms at a single page. If an address gets a new ID everytime a form is updated, well, then you ask for trouble. I seem to have worked around this problem in all places an address form is used and we can do this for the order form too, but it would be better to deal with the same address object everytime when an address form is updated via ajax.

We could use a developer here who has a deep understanding of the Form API and especially knows what exactly the Form API does when forms are processed/constructed via ajax using the #ajax property.

MegaChriz’s picture

I've opened the issue #1471500: Issues with the uc_addresses_address element to work on the zone field issues reported in #12. This is probably the same issue as Jay Matwichuk encountered in #4.

The "Nesting level too deep" error can be still handled here.

Michael-Inet’s picture

Both of these are after turning off Shipping quotes (and dependencies):

In /admin/store/orders/33/edit, I get this after changing the Bill to:, Country and State/Province fields and clicking Submit Changes:

    * Notice: Undefined property: stdClass::$billing_aid in uc_order_edit_form_submit() (line 1067 of sites/all/modules/ubercart/uc_order/uc_order.admin.inc).
    * Notice: Undefined property: stdClass::$billing_uid in uc_order_edit_form_submit() (line 1067 of sites/all/modules/ubercart/uc_order/uc_order.admin.inc).
    * Notice: Undefined property: stdClass::$billing_address_name in uc_order_edit_form_submit() (line 1067 of sites/all/modules/ubercart/uc_order/uc_order.admin.inc).
    * Notice: Undefined property: stdClass::$billing_default_shipping in uc_order_edit_form_submit() (line 1067 of sites/all/modules/ubercart/uc_order/uc_order.admin.inc).
    * Notice: Undefined property: stdClass::$billing_default_billing in uc_order_edit_form_submit() (line 1067 of sites/all/modules/ubercart/uc_order/uc_order.admin.inc).
    * Notice: Undefined property: stdClass::$billing_created in uc_order_edit_form_submit() (line 1067 of sites/all/modules/ubercart/uc_order/uc_order.admin.inc).
    * Notice: Undefined property: stdClass::$billing_modified in uc_order_edit_form_submit() (line 1067 of sites/all/modules/ubercart/uc_order/uc_order.admin.inc).

and the address isn't updated.

Possibly related? I get this at /admin/store/orders/view?order_id=&order_status=All&=Apply :

    * Ubercart cannot find a necessary encryption key. Refer to the store admin dashboard to isolate which one.
    * Notice: unserialize(): Error at offset 0 of 124 bytes in uc_credit_cache() (line 741 of sites/all/modules/ubercart/payment/uc_credit/uc_credit.module).
    * Notice: unserialize(): Error at offset 0 of 124 bytes in uc_credit_cache() (line 741 of sites/all/modules/ubercart/payment/uc_credit/uc_credit.module).
    * Notice: unserialize(): Error at offset 0 of 124 bytes in uc_credit_cache() (line 741 of sites/all/modules/ubercart/payment/uc_credit/uc_credit.module).
    * Notice: unserialize(): Error at offset 0 of 124 bytes in uc_credit_cache() (line 741 of sites/all/modules/ubercart/payment/uc_credit/uc_credit.module).
    * Notice: unserialize(): Error at offset 0 of 124 bytes in uc_credit_cache() (line 741 of sites/all/modules/ubercart/payment/uc_credit/uc_credit.module).

# # #

When turning Shipping Q's dependencies back on, I get this at /admin/modules :

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'fetch_task::sharethis' for key 1: INSERT INTO {cache_update} (cid, created) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1); Array ( [:db_insert_placeholder_0] => fetch_task::sharethis [:db_insert_placeholder_1] => 1331317843 ) in _update_create_fetch_task() (line 245 of modules/update/update.fetch.inc).

But it goes away, after clearing cache.

/admin/store/orders/view?order_id=&order_status=All&=Apply still has the same errors.

And if I manually move an order back to "In Checkout" /cart claims I don't have any products in my shopping cart. (huh, nevermind, on an instance that has never had uc_address, this is now happening as well. UC brake something else?)

And that's it for this week, hope you have a great weekend,
Sam

MegaChriz’s picture

I've committed some changes to the 7.x-1.x branch. The patch posted in #11 still applies when using patch -p1 < uc-addresses-order-form-1424038-11.patch, but not when using git apply uc-addresses-order-form-1424038-11.patch.

@Sam-Inet
The patch isn't finished yet. It's intended to be used as a starting point for fixing this issue. Before we can seriously continue with this one, #1471500: Issues with the uc_addresses_address element need to be reviewed and fixed.

MegaChriz’s picture

#1471500: Issues with the uc_addresses_address element is done now. We can now continue with fixing this issue.

MegaChriz’s picture

StatusFileSize
new98.25 KB
new8.49 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch uc-addresses-order-form-1424038-17.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Here is a new patch to be used as a starting point for fixing this issue. The differences with the patch posted in #11 is it's now in line with the changes done in the uc_addresses_address element (see also #1471500: Issues with the uc_addresses_address element).
It also fixes one of the errors noted in #14 (about undefined properties).
In my installation, selecting an address is working fine and somehow I don't get the "nested level too deep" error anymore (as reported in #12). I think this is no longer an issue since the fundamental changes in the uc_addresses_address element. It can also because I didn't do a wide test yet (with modules turned on and off).

The next steps for fixing this issue:
- Implement "copy address". This should not work exactly the same as on checkout. It should be possible to copy addresses in both directions without collapsing the forms.
- The address selector should be "hidden" by default. That is because the label for a selectable address can be very long and that can cause (very) wide address panes (see image).
- The automated tests should be updated (I will work on that part when the two first bullets are done).
- The fix should be tested with several configurations (for example: with uc_quote module turned on and off)

MegaChriz’s picture

st455’s picture

Hi MegaChriz,

Thank you for your direction on #1529960. From my initial tests, the patch seems to be working great. Also, from the image that you attached along with the patch, i see that you added an extra text box to the address field (i mean, usually street address field has just two text boxes), I would like to know how you achieved that. I am trying to have three text fields for the street address.

Thanks.

MegaChriz’s picture

Title:[$150 Bounty] Order administration feature» Order administration feature
Assigned:Michael-Inet» MegaChriz

@st455
Ubercart Addresses 6.x-2.x and 7.x-1.x have support for adding extra address fields through the field handler api. I'm working on an example module to demonstrate that. Currently, the example module's documentation is a bit short and it also demonstrates only one type of field (a simple text field) and that's why I hadn't published it yet. However, I think I will include it with the Ubercart Addresses package this week, as it's quite useful to have an example, although it less good documented.
There is no UI for adding extra address fields, it's only possible to do so via the API. For Ubercart Addresses 6.x-2.x, Extra Fields Pane delivered that UI (in the form of supporting only a few field types), but I haven't had the time yet to port that module to Drupal 7. Ideally, the UI would be delivered by the Drupal 7 field API (or maybe it should even replace the Ubercart Addresses field handler API), but that is an idea for the far future. At this point, I'm not even sure if I will ever come to that point.

I'm currently working on this issue; I'm taking the steps as noted in #17. As it less easy as I had expected, I will commit the patch in #17 soon as it fixes also the now broken order administration section.

MegaChriz’s picture

Patch in #17 is committed:
http://drupalcode.org/project/uc_addresses.git/commit/e070d2a
http://drupalcode.org/project/uc_addresses.git/commit/4170010

In two commits this time, I got interrupted when doing changes and forgot to remove debug code and doing a code review when I did the first commit.

New problem detected:
- When an order is created for a customer with no addresses in the address book, but with previous orders, selecting an address will result into errors: the familiar "Illegal choice" error (zone issues).

So, to sum up what needs to be done before this issue is fixed:
- Implement "copy address". Should work just like Ubercart one's except it should be done via Ajax.
- Hide the address selector by default, just like Ubercart does.
- Fix selecting addresses for customers with no addresses in the address book.
- Update automated tests (partly done now).
- Testing with several configurations.

MegaChriz’s picture

Edit: duplicated comment.

st455’s picture

@MegaChriz We implemented the field handler and got a new field to display in the checkout form. However, since the field happens to be part of our address field, we want to load it along with our address. Is there any way we can get the "aid" value for a given order id? Currently, there is no explicit relation between aid and order_id since addresses are saved for user. Buy as you know when we have to load orders for "edit" mode in the backend, we need to know which address(aid) should be picked.

Thanks.

MegaChriz’s picture

@st455
There is no relation between the uc_addresses and uc_orders table. Addresses for an order should be stored in the uc_orders table.
I have added an example module to the 7.x-1.x version that demonstrates a way of adding address fields that will work with both the address book and Ubercart orders. Hopefully, you will find the answers there. If not, please open a new issue if you have further questions about extra address fields.

pthurmond’s picture

Why don't you just create a join table so that you can associate addresses to the uc_orders table? This could be done for any table association with addresses. Just have two columns, the address row id and the order id. The combined key will be the primary key.

MegaChriz’s picture

Assigned:MegaChriz» Unassigned
Status:Needs work» Needs review
StatusFileSize
new18.47 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch uc-addresses-order-admin-feature-1424038-26.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

The following patch fixes the following for this issue:
- The return of the "copy address" feature, but now implemented via Drupal Ajax Framework/Drupal Form API.
- The address selector is hidden by default (just as is the case in Ubercart). Also done with Ajax technics.
- Selecting addresses from previous orders should work again.

Since this patch changes a lot of code, please test if it doesn't introduce any new bugs or rare side effects.

@pthurmond
The records in the uc_addresses table are pure used for the customer's address book and thus it make no sense to link them with the uc_orders table. Addresses for the Ubercart order are saved in the uc_orders table. This is the default Ubercart behavior and Ubercart expects the addresses to be there.

Status:Needs review» Needs work

The last submitted patch, uc-addresses-order-admin-feature-1424038-26.patch, failed testing.

MegaChriz’s picture

Status:Needs work» Needs review
StatusFileSize
new2.46 KB
new18.17 KB
PASSED: [[SimpleTest]]: [MySQL] 2,174 pass(es).
[ View ]

Hm, including images to a patch doesn't seem to work. Here's a new patch. The images are attached separately.

Again, this are the fixes:
- The return of the "copy address" feature, but now implemented via Drupal Ajax Framework/Drupal Form API.
- The address selector is hidden by default (just as is the case in Ubercart). Also done with Ajax technics.
- Selecting addresses from previous orders should work again.

Please test if there no new bugs introduced or other side effects.

MegaChriz’s picture

StatusFileSize
new20.48 KB
PASSED: [[SimpleTest]]: [MySQL] 2,174 pass(es).
[ View ]

Here's a new patch, with a few changes. The "copy address" feature didn't work at all in the last patch, because I accidentally removed a function that was still used as the ajax callback of the copy address function. For the rest some little fixes/cleanup to the address select field element, that's introduced to fix selecting addresses from previous orders. I would like to separate these two fixes, but since their so tight well together now it will take more time than I can spend now. I'm happy to hear opinions.

Michael-Inet’s picture

Hi Youri,

Started on this, first problem is with Drush not liking the .info dependencies list:

[localhost uc_addresses]$ drush en uc_addresses
No release history was found for the requested project (uc_store).                                                       [warning]
The following projects have unmet dependencies:
uc_addresses requires token, ctools
Would you like to download them? (y/n): y
Project token (7.x-1.1) downloaded to /var/www/html/virthosts/uc_addresses/sites/all/modules/token.                      [success]
Project ctools (7.x-1.0) downloaded to /var/www/html/virthosts/uc_addresses/sites/all/modules/ctools.                    [success]
Project ctools contains 9 modules: views_content, bulk_export, ctools_custom_content, ctools_ajax_sample, ctools_plugin_example, page_manager, ctools_access_ruleset, stylizer, ctools.
No release history was found for the requested project (uc_store).                                                       [warning]
Module uc_addresses cannot be enabled because it depends on the following modules which could not be found: uc_store     [error]

Manually adding dependencies[] = ubercart to the .info didn't help. Drush goes into a dl ubercart loop (and keeps asking to overwrite ubercart). Seems a drush issue? http://drupal.org/node/1511984 "Drush does not yet have any way to do the reverse mapping from the module name to the project name." As there is no drupal.org/project/uc_store . There may be a way to force drush to dl/en ubercart before trying to dl uc_store, but I'm not sure what it is. (I'll open a request for clarification ticket in drush)

Manually dl ubercart and then en uc_store lets drush enable uc_addresses.

Might want to add a note about this to the readme.

I'll work on the rest tomorrow.

Best,
Sam

MegaChriz’s picture

The dependency should be "uc_store", which is one of the modules Ubercart Addresses depends on. But "uc_store" is not the name of the project. Changing the dependency to "ubercart" wouldn't be right because that's not the name of a module Ubercart Addresses depends on. As I read the issue you posted a link to, it looks like Drush tries to download the dependencies, but doesn't have the sufficient information to do so, because drupal.org doesn't seem to provide enough information for Drush. I guess the easiest to do is to just downloading the dependencies manually. I have not much experience with Drush, but maybe Drush doesn't complain anymore when all the dependency modules are present?

Michael-Inet’s picture

Category:task» bug
Status:Active» Needs review
Issue tags:+bounty
StatusFileSize
new3.78 KB

>> Changing the dependency to "ubercart"

No, I was adding “ubercart” to the dependency list. In the vain hopes drush would figure it out, which it didn't.

And yes, it's a drush problem.

Though I do highly recommend using drush, it saves huge amounts of time. Although you're on a MAC/OSX?, which might complicate installing it, but it's still very valuable for quickly building sites. Here's my site install script, which builds a site in a minute or two. If you can't run a bash script, just strip out the drush commands.

Best,
Sam

Rename it to "d-site-install.sh"

MegaChriz’s picture

StatusFileSize
new2.46 KB
new8.41 KB
PASSED: [[SimpleTest]]: [MySQL] 2,233 pass(es).
[ View ]

I have committed a part of #29. This part introduced a new form element called "uc_addresses_address_select" and is there to fix the issue of selecting addresses from previous orders. I have moved this part of the issue, which is related but actually a different issue in #1701324: Selecting addresses from previous orders fails.

Here is a new patch, a sort of "re-roll" of #29. There are no new changes, just the fix for #1701324: Selecting addresses from previous orders fails has been removed from it.

The images folder in images.zip should be placed in the root of the uc_addresses module folder.

MegaChriz’s picture

Title:Order administration feature» Order administration: "copy address" feature
Issue tags:-bounty, -7.x-1.0-alpha1

Removed the tags. The last piece for the order administration feature - the "copy address" feature - will be implemented later.

jvieille’s picture

I have the same problem, but with the D6 version.
The selected addresses are not saved in manual orders.
Does this patch exist or is it needed / relevant for D6?

MegaChriz’s picture

@jvieille
This issue is about selecting addresses from the address book in the order administration for the 7.x-1.x version. This works differently than for the 6.x-2.x version. For the 7.x-1.x version, Drupal's AJAX framework is used to apply addresses. In the 6.x-2.x version this is done with just javascript.

One piece that is missing for this issue is the ability to copy addresses from the shipping to the billing pane (and vice versa). This feature is originally provided by Ubercart, but Ubercart's version doesn't work with extra address fields as it uses "plain" javascript and only cares for the fields it knows. That's why the feature is removed at the moment with Ubercart Addresses installed. It should be replaced by a solution using Drupal's AJAX framework, but I haven't been able to figure out a neat solution. The patch in #33 needs extra CSS in order to style the copy button similar as in Ubercart, but this CSS may be to aggressive: hard to override by themers. A solution using a simple link is not supported by Drupal's AJAX framework, because there wouldn't be a fallback when javascript is disabled.

MegaChriz’s picture

StatusFileSize
new25.46 KB
new2.72 KB
new7.64 KB
FAILED: [[SimpleTest]]: [MySQL] 5,222 pass(es), 12 fail(s), and 0 exception(s).
[ View ]

I never liked the fix in #33 where it was needed to add images to uc_addresses that are already present in Ubercart. I thought a long time how to come up with a nicer fix that doesn't require the extra images. I finally came up the idea to fix the problem the way the Rules module did: on some places in Rules UI, a smaller button is shown:
1424038-rules-ui-button.png

The following patch implements the copy address button, but doesn't include all the features from the patch in #33.
An overview of the changes:

  • A copy address button is placed below the address book select field.
  • The code checks if it expects the other pane to be present and only shows the copy address button if this is the case. For example: if the bill_to pane is disabled, no copy address button is shown in the ship_to pane.
  • Order panes are renamed from "delivery" and "billing" to "ship_to" and "bill_to" respectively, just as usual in Ubercart.
  • CSS is added to style the copy address button the same as in the Rules UI.

Plus, compared to the patch in #33:

  • CSS for styling the copy address button as an image has been removed.
  • Images are removed.
  • The address selector is always shown.
  • The button for showing/hiding the address selector is removed.

This is how the address panes on the order admin screen now look like:
1424038-order-edit-37.png

This needs some manual testing to ensure all address related features still work (address selecting, zone selecting, copying addresses, etc.). But let first see if it passes the automated tests.

Status:Needs review» Needs work

The last submitted patch, uc-addresses-order-admin-feature-1424038-37.patch, failed testing.

MegaChriz’s picture

Status:Needs work» Needs review
StatusFileSize
new9.47 KB
PASSED: [[SimpleTest]]: [MySQL] 5,232 pass(es).
[ View ]

In addition of the patch in #37, this patch adjusts the order test case: it informs the test that the element in the form has changed from "billing" to "bill_to".
No other changes were made.

MegaChriz’s picture

Status:Needs review» Fixed

I manually tested address selecting, zone selecting and copying addresses and didn't encounter issues with it. I even tested together with Extra Fields Pane. In combination with that module copying addresses doesn't work properly (extra field values aren't copied over), but that should be fixed in Extra Fields Pane which will I do later.

Committed #39.

MegaChriz’s picture

A patch for Extra Fields Pane is available in #1997842: Adjust order administration. It will be committed after a new release of Ubercart Addresses 7.x-1.x is made.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.