Jump to:
| Project: | Ubercart Addresses |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | MegaChriz |
| Status: | closed (fixed) |
Issue Summary
Problem/Motivation
For the 7.x-1.x and 6.x-2.x version Views integration is planned. A part of the integration is already done and is included in the latest releases (7.x-1.0-alpha1 and 6.x-2.0-alpha2 by the time of writing).
Remaining tasks
There are several things left to be implemented to complete Views integration:
Row style: fields(added to 7.x-1.0-alpha1/6.x-2.0-alpha2)- #1942748: Views integration: address row style
- #1900150: Views integration: address access filters
- #1900176: Views integration: address view, edit and delete links
- #1908904: View integration : needs a relationship in the user based views
- #1942746: Views integration: display access restrictions
- Automated tests
- Default view for the address book page: #1433034: Redesign the address book page using Views
Some of the noted features above depend on entity integration to be completed:
#1831424: Turn Ubercart Addresses address into an entity
User interface changes
Site builders get new options in Views.
API changes
None.
Original report by MegaChriz
There should be a new View type created which will be called "Ubercart Addresses". This view type should support two row styles:
- Fields
- Address
Row style: Fields
For the fields row style, Views will pull the data itself right from the database, so the address book API shouldn't get involved here. The Views field handlers should be connected with the Ubercart Addresses field handler API: the output of values should go through outputValue(). The Views field handlers to be implemented should respect the output formats the Ubercart Addresses field handler supports (see getOutputFormats()).
Row style: Address
See #1942748: Views integration: address row style.
The address row style will be used to display addresses themed with "uc_addresses_list_address".
For the address row style, the address book API should be responsible for loading the addresses from the database. Views should only load the address ID (aid) and user ID (uid) from the uc_addresses table and then pass this values to the address book API which will care for loading full UcAddressesAddress objects. To increase performance, the address book API should be informed to load all addresses for one user at once. This can be done by setting the performance hint to UcAddressesAddressBook::PERF_HINT_LOAD_ALL.
Filters
See #1900150: Views integration: address access filters.
There should be a Views filter for every database column of the table "uc_addresses". There should also be filters to filter on address access:
- A filter for if the address may be viewed.
- A filter for if the address may be edited.
- A filter for if the address may be deleted.
Other acknowledgements
- You can use the module uc_views_addresses (part of the Ubercart Views project) as a starting point, but there should be no longer a dependency on Ubercart Views (output of Views field handlers should go through the Ubercart Addresses field handlers).
- It's possible that the field handler API needs to be a little bit adjusted to ease the Views integration. You may come with a proposal.
- The Views integration should be implemented for both the 6.x-2.x and the 7.x-1.x branch.
I'm happy to assist where possible. Contact me or place a comment on this issue page.
Note: I may make some edits to this post in case I have something forgotten to note in the proposal.
Comments
#1
Feature: Should also have fields and filters for the default flags.
This is not available on the current version and makes views of mailing labels not possible because you also get shipping addresses.
Filters
- filters by if none, billing, or shipping
Field
- shows if none, billing, or shipping
What do you think?
#2
@CraigBertrand
Filters and fields for the default flags are planned. In version 6.x-2.x (and 7.x-1.x) these default flags have been moved to the uc_addresses table (the uc_addresses_defaults table has been removed).
I had planned to implement them as separate fields/filters. Thus you could add a "Default shipping" filter and a "Default billing" filter. These two filters would operate similar as the "Node: Published" filter.
#3
Sounds fantastic!
Is this feature in the 6.x-2 alpha 1 version? I would be happy to help test it and report back what I find. We are using ubercart for a non-profit child sponsorship sites CRM and uc_addresses is a major part of it.
Thanks so much for your work!
#4
No, there is no Views integration in the 6.x-2.x-alpha1 version. It is planned to be implemented for 6.x-2.x-alpha2 and 7.x-2.x-alpha2. For Ubercart Addresses 6.x-1.0 there is views integration available in the module uc_views_addresses, part of the Ubercart Views project. Some code of this module can be reused when implementing Views integration for the 6.x-2.x and 7.x-1.x version.
#5
Okay, I will patiently wait ;) I am currently using version 1 and uc_views and initially found this post when trying to figure out how to filter by default. Thanks again.
Is there anything a non-php coder can do to help you?
#6
@CraigBertrand
You can always help with testing the module:
- Report any bugs you may find.
- Check text strings for readability/clarity. Do you understand the message that is displayed? Are there spelling errors in the message?
- Is the module user friendly? How could it be made more user friendly? (There is already one issue about improving the user interface: #1433034: Redesign the address book page using Views)
- Try out the features of the module with different settings.
- Try to do some less expected things with the module, such as fill in html markup, constantly mark other addresses as the default shipping / billing, changing the country over and over again and anything what you can think of more.
- Check if the permissions are respected everywhere. This is mostly already covered by the automated tests, but there may be use cases in which this doesn't work like expected, such as reported in #1414462: Users Without Permission Can Still Add New Address While Checking Out. In that particular issue I'm not sure yet what to do with it.
This won't speedup the integration with Views, though, but it can help making the module more stable and more user friendly.
#7
Basic Views integration for the 7.x-1.x version has been added
I got some help from user phead for implementing Views integration for the 7.x-1.x version. Basic Views integration has now been added to the 7.x-1.x version of the module! This means that now an address view can be created using fields. What's not included yet is:
Todo
See commit.
I'll be working on back porting the new code to the 6.x-2.x version.
#8
Will there be the ability to see custom fields?
#9
@samgreco
That depends on where the values for custom fields are stored. If they are stored in the uc_addresses table, Ubercart Addresses will expose them to Views, but will assume they are just text fields. If the values for custom fields are stored in a different table (like Extra Fields Pane does, for example), then it's up to the module that implements the custom fields to expose them to Views. (Extra Fields Pane 7.x-1.x doesn't expose it's custom address fields yet).
#10
Basic Views integration for the 6.x-2.x version has been committed! From now on, don't enable the uc_views_addresses module (part of the Ubercart Views project) as that may give conflicts. That module was written for the 6.x-1.x version of Ubercart Addresses anyway.
If you've used the uc_views_addresses module in combination with Ubercart Addresses 6.x-2.x, then note that you may have to reconfigure zone and country fields in your views.
#11
Looks good.
Missing feature: the ability to use uc_addresses fields in other views type, specifically the "user" type view.
#12
I've opened a new issue for implementing the address access filters: #1900150: Views integration: address access filters.
I thought it would be a good idea to split out the extended Views integration into smaller code changes, so you won't get one big patch with several additions for Views.
#13
I've opened an new issue for implementing Views fields for view, edit and delete links: #1900176: Views integration: address view, edit and delete links.
#14
The 7.x-1.x version has the highest priority at the moment.
#15
Fixed in dev
The following features have been added to the dev meanwhile:
This allows you to filter out addresses from the Views results that an user is not supposed to see.
When using the fields row style in Views, you can add:
Access checks are performed before the links are displayed. For example: the edit link is not displayed when the current logged in user may not edit the address.
Display addresses in user based views.
To be fixed/implemented
I have created two new issues for Views integration:
With this feature you should be able to create an address listing where the addresses are displayed just like on the address book page (user/[user:uid]/addresses).
With this feature you should be able to restrict access to the whole Views display by performing access checks based on contextual filters (arguments) for "User ID" and "Address ID".
#16
Features #1942748: Views integration: address row style and #1942746: Views integration: display access restrictions are now added to the 7.x-1.x-dev version (7.x-1.0-alpha1+25-dev).
It would be great if you want to test out #1433034: Redesign the address book page using Views: a View that will replace the address book page.
#17
All tasks for Views integration have been completed!
You now have the following options for Ubercart Addresses in Views:
I hope to create new releases later this week.
#18
Thanks a lot
What about 6.x?
#19
@jvieille
Good question. All features for Views have been added to both 6.x-2.x and 7.x-1.x.
#20
Automatically closed -- issue fixed for 2 weeks with no activity.