I made an extra option in the uc_addresses admin to not allow editing the delivery and billing address fields in checkout. Only the available addresses from the My Account pages can then be chosen.

If that option is active all delivery and billing fields are set to readonly. They are still shown, because if you would omit the panels, the addresses are also not shown on the order review and the invoices. I chose for "readonly" and not "disable", because disabled field values are not posted.

Because readonly is not a valid tag for "select" fields I used the readonly jquery plugin for that.
For now I added the jquery.js en .css in the uc_addresses module dir.

If you think this is a good feature I'll gladly make a more appropriate solution for the jquery files. (There are quite a few in drupal world, have not decided which I prefer)

Place the .js and .css file in the uc_addresses dir and use the patch file in the /sites/all/modules dir.

(This patch is related to http://drupal.org/node/498738. With both you can get more control over the addresses used by the store customers)

Files: 
CommentFileSizeAuthor
ucaddress.patch.zip4.34 KBcatorghans

Comments

First of all, I appreciate your dilemma: you have a client that needs a unique feature. You can patch uc_addresses to make this feature available. If you patch just your own version, though, the next release of uc_addresses will wipe out your changes. If you branch off and create your own special version, you will have to manually integrate any future bug fixes and enhancements made to uc_addresses.

Now here's my dilemma: every additional feature added to uc_addresses increases the testing time (imposes another set of cases to check), increases future porting time (more code to port—and test), potentially lowers performance and introduces a risk of side-effects.

The patch in the related enhancement request seems pretty innocuous but I am still considering it whether I want to add the feature to the base code. This patch seems less attractive since it starts to hack into the checkout page much more than I like. I understand that the first page is useless without this one, so the whole package starts to look like a lot of complexity for the rather odd needs of one client.

My current tendency is to not add this feature unless I hear some good arguments for how it adds value in general. In other words, why does your client need this feature and is this a need that other store owners would be likely to to have?

I have occasionally had to deal with this kind of issue myself. Where I couldn't justify a general change, I've duplicated the module, renamed the files and functions, made my changes to the new code and accepted that this module will have to be manually maintained in the future (I also inform the client about the ramifications of playing on the edge).

So, if you like, you can make a case for adding this patch to uc_addresses. If anyone else has a similar requirement, post a message and tell us about it.

Thanks for the response.

Yes, this customer has very specific demands, so I can imagine very well that this functionality does not become part of uc_addresses. Hopefully today I'll add another patch, which adds VAT functionality to uc_addresses. I'll leave it up to you if one,2 or all 3 become part of the code somehow. Otherwise these issues might help people who have similar requests and are not afraid of patching.
I have to create it anyway. If it helps to make uc_addresses become better, that would be great. If not, no loss for me.

But I can give you some reasoning why I would think this option makes sense for more people then only my customer:

uc_addresses gives an extra, very powerful way to manage the addresses used in ubercart. It helps people to reuse an address lots of time, to check it thoroughly to minimize mistakes in the address fields used. Managing the addresses in My Account makes a lot of sense for people who use the shop more often. Especially for B2B shops a well checked and managed address can prevent income loss and legal problems. It is in the interest of shop owners as well as buyers.

At the same time uc_addresses leaves the old way of managing addresses intact. The checkout panel address fields are so easily adapted that it is very easy to make mistakes. That creates a wrong order and a wrong invoice. It also adds a wrong address in the uc_addresses list, which makes it easier that the mistake is made again.

I think it makes sense that if you create a superior way of address management, that you at least give the option to not use the other (less superior) way.

I agree that having the patches available are useful to those who run into the oddball cases and I appreciate your effort in donating them.

Don't know if you're interested, but here's a proposal if you would like to see this feature folded into uc_addresses, which has the benefit of simplifying your future updates.

First, start with your patch to add a new permission: edit own addresses. Make sure that, by default, this permission is enabled for logged in users.

If the site owner enables address entry during registration, we will assume that this trumps the edit own addresses permission. I believe you already allowed for this.

However, the options to save addresses entered during checkout will be disabled. It doesn't make sense to keep this ability when users cannot edit their addresses. So the edit own addresses permission trumps the checkout address saving settings.

Patch the README file to explain all this.

What about making the address fields in the checkout are read-only? I would rather not incorporate that feature into uc_addresses. However, you can implement that in a module of your own—it really has nothing to do with uc_addresses. In other words, uc_addresses manages an address book and supplies addresses to other modules; it doesn't dictate how those addresses should be used. An "edit own addresses" permission simply says whether the user can enter or edit addresses in the address book.

The patch should include any needed changes to module installation (uc_addresses.install) and removal (I don't think there are actually any). Test the registration process, the user account and the checkout to make sure it works appropriately with the new permission on and off and with some of the other relevant uc_addresses settings (saving checkout addresses on/off, require address at registration on/off) and I'd be willing to apply the patch.

It's a lot of work and I won't blame you if you decide not to take it on. However, I think you might be pretty close already. If you decide to go for it, I'd appreciate it if you included a checklist of the cases you tested.

Thnaks!

Thanks,

I agree with your view. I'll create a different module for read_only checkout fields and I'll create a patch for the "add/edit own address" according to your wishes.
So, what about the VAT handling which I'm working on? I think it makes sense to add it to uc_addresses.

For using VAT in ubercart with uc_addresses there are 2 things to think about:
-adding/editing VAT field within uc_addresses
-using VAT in ubercart

The first one is part of the address and should be build in uc_addresses (I think).
The second one might be different, because VAT handling is not part of ubercart core, but is done by several contribs,
http://drupal.org/project/uc_vat_number
http://drupal.org/project/uc_vat

I'm using the first. If I'm following the VAT discussion right it seems there is still no preferred way to handle VAT within ubercart community, and for the foreseeable future it will not be part of ubercart core (http://www.ubercart.org/forum/development/10901/ubercart_3x_battle_plans). So it might be logical that the handling of the VAT with the different contribs is not done within uc_addresses.

I'll make the first patch like the previous ones and build it in uc_addresses locally. And we'll see later if (and how) it will be added to uc_addresses.

If the VAT field is part of an address and if it is needed by a number of Ubercart users, then I would be inclined to include a patch.

All I know about VAT is that one possible interpretation is Value Added Tax. I'm not sure how a tax is part of an address. Could you give me a short explanation of what VAT stands for and its relationship to addresses?

By the way, I was hoping that uc_addresses would become a core feature. I guess I'm off to the battle plan thread!

Every business in Europe has a VAT number, it is printed on every invoice with the address.

If you do business with an other company you need to have their VAT number as well.
It is part of a business address in Europe.

Assigned:Unassigned» freixas
Status:Needs review» Postponed

This feature request has been marked postponed, which is my way of saying that it probably won't get included in the foreseeable future, but that it has some merit and shouldn't be discarded.

Title:extra option for only using uc_addresses and not allowed to edit the delivery and billing address fields in checkoutalignment in uc_addresses

Hi,
I have added this module,everything works perfect,i want the address fields to be placed side by side in the form.(How to edit the position of the fields).

Need help...

Title:alignment in uc_addresses extra option for only using uc_addresses and not allowed to edit the delivery and billing address fields in checkout

Restoring original issue title.

@jhansi: Please do not hijack other people's problem reports. Create a new one.

Hi all,
Not sure if this is a live topic anymore, but I wanted to cast my vote for the inclusion of strong edit permissions within uc_addresses.
Like catorghans, I have a customer who wants to restrict the shipping and/or billing addresses for purchases. The use case is...

Certain customers are given special consideration. They get a huge discount as "retailers" of the products which are only purchasable via the Drupal site. These special users are identified, invited, and have accounts created manually by my client. The client wants to protect against abuse of this discount so that users cannot use the discount and send products where ever they wish.

I am exploring the options laid out in the posts above, but the drawbacks are a bit hard to live with (dodgy upgrades, my own PHP skills are less than Jedi, etc)

Anyway, Im hoping for a reprieve and these features are included within the module(s) so at least my upgrade path is free of obstacles.

Thanks to all for the helpful posts above and to bendiy, psynaptic, and freixas for developing uc_addresses

It feels like what you really want is not uc_addresses, but a customized module that allows an admin to define a single shipping address for a customer, automatically fill the shipping address during checkout (maybe also if admin creates an order?) and prevent the shipping fields from being edited.

It is VERY unlikely that I will adapt uc_addresses to work the way you want. However, I'd be happy to develop a module (as described above) at my usual rates. Send me a note if you're interested.

Assigned:freixas» MegaChriz