Dependent Attributes: To specify a charity

[LilleyPadGifts]

Understood the first part of that but not the last paragraph. And yes it has to be on every product. This is a option per product, NOT per total sale.

[LilleyPadGifts]

I really thought that Dependent Attributes sounded like what I needed.

[mc12345678]

I really thought that Dependent Attributes sounded like what I needed.

Yes in a small part. In order to get to the one team member, being able to filter down through the options is related to dependent attributes. How that is implemented is kind of the discussion right now.

See, populating the database to allow this grouping of attributes to be singly applied to all product, well, basically that takes a lot of database space.

What I believe is being suggested and it can be implemented a number of ways is to offer something that can be selected by the shopper (yes it could use a product that has the dependent attributes, but that has to be worked into the shopping flow). Things of consideration is that, typically if someone is logged in, they have their "normal" benefactor (affiliate), but there may come a time when one of the children takes up a different sport, or one comes of age, etc... to where a shopper may have multiple from which to choose just to support their own home. Anyways, there are a number of ways to implement it all, there's existing plugins that can be repurposed (I believe that was lat9's suggested path as well.) and there are some things that may need unique customization. I mean if you were okay with a fily making one purchase per "child" you could enforce the "choose your child" product and all purchases would go to that one purchase on that order.

[LilleyPadGifts]

There isn't a "normal" benefactor. No, I would not be happy with that at all.
I think I understand to a point what you are suggesting but when a customer comes to the site to order they might order 5 different things with 20% of each item going to 5 different registered groups. It needs to be in one order ...meaning they are not going to buy one, check out, buy another.... and the only actual work of that choice is to print those choices per item on their order when we print it out and when they print it out.
What are the results of a huge database? Slow to load? Won't load at all?????

[mc12345678]

There isn't a "normal" benefactor. No, I would not be happy with that at all.
I think I understand to a point what you are suggesting but when a customer comes to the site to order they might order 5 different things with 20% of each item going to 5 different registered groups. It needs to be in one order ...meaning they are not going to buy one, check out, buy another.... and the only actual work of that choice is to print those choices per item on their order when we print it out and when they print it out.
What are the results of a huge database? Slow to load? Won't load at all?????

Well, from an educational perspective may I recommend reviewing database setup in particular associated with normalization. I forget which normal order such a condition would fall into, but basically saying that every product must have this selection possible, but understand that not every product needs to have a multitude of other "attributes", so it tends to be more efficient to have such a selection centralized to its own "area" (suggested was an affiliates program type relationship). The information associated with that selection could be stored within a session associated with each product and it could even end up being stored in the orders related tables as part of the purchase, but all that is part of the development process.

You asked about the dependent attributes aspect, well, yes to make some form of entry either by you as an administrator or by the customer for selection that they would want to have some of dependent attribute entry to simplify recall/use of the selections. But having all of those attributes actually associated with every product rather than as a selection that needs to be made while working with a product where the selection is "simple" but the result powerful. As said can see a number of ways of implementing and pretty much everyone has their own idea of how to accomplish the task, but it comes down to long term maintenance, growth, consistent easy use, etc... and compared with what is needed when (ie. need now, more likely to cram something in that works, but may be tough to manage, etc...)

A real quick on the database part... If you populated every product with the same group of attributes where say 5 sports, 50 states, each state having say 3 "levels" of sport, each having at least 10 "cities", then there are a minimum of 10 members per team that's at least 75,000 database entries for a single product, now how many products are we talking about? And if one player is added or removed to/from another sport, then every product has to be updated to reflect that one change instead of updating a single location one time...

[LilleyPadGifts]

Sorry you are losing me again....
"not every product needs to have a multitude of other "attributes""
They will all need to have this. There isn't a few products that need this, they ALL need this. So maybe I'm not understanding what you are saying. For some reason what I read is over technical and my brain can't process it ...probably this flu bug I have... but still... Currently I have used the Attribute function for this process on my old site but with only one example added. I installed a addon that lets you add the attribute to a group of products all at once... don't remember how it works exactly. My only concern was that as the list grows its a drop list that goes on and on. The database being overloaded was never a issue that was brought up.
Maybe it can be added another way, but it has to be per product, per sale, NOT per invoice. I started this business myself and it was doing phenomenal until we had to relocate...so I know what works and what the issues are that arise. This is why I'm so adamant on getting this set up correctly, hopefully for the money I am paying him he will make it work but if not, as mentioned before, I will have to do this myself and that means delaying this whole project by months which is NOT a good thing.

[LilleyPadGifts]

I guess to put it plainly .... can ya dumb it down a bit so I can understand what you are suggesting ? Lol

[Website Rob]

I think problem with replying is that you have not clearly enough stated the problem.

Would this be close.

You want something like the following (on which page?) in the checkout process.

Multiple drop-down boxes with each following drop-down dependent upon what is selected in the preceding drop-down.

Sports
-> Baseball
....-> California

Then California will have a list showing x number of selections as well?

If yes, that is Sports, Baseball, California, final select = 4 drop-downs and who knows how many of these entries per product. Plus you want all 4 selections to be printed on customer and site invoices?

There is a module that might come close to what you want, Product Finder Multiple Category Drop-downs. Read the last page of the support thread as there is newer version at github.

[LilleyPadGifts]

It has to be a mandatory field on the product page as they customize the product, not on the checkout page because it must be per product NOT per order.
I just thought this type of add on would help simplify the customer's view of the drop list but now I see there are other concerns as far as the database is concerned. Some products already have a couple 100 attributes because they are custom charms to be added and this would add a endless list of attributes.
As far as all of the Catagory levels showing on the invoice, no it would just be the bottom level because there would be a number in the title for my use to locate who the funds go to. Not all would have as many category levels. Sports is just the one that involves more. Animal charities wouldn't have to be broke down as far and neither would Causes.
So again, the only problem I had was adding levels to the categories that I was added via attributes. Now I have a whole new issue and that is the burden on the database.

[mc12345678]

I guess to put it plainly .... can ya dumb it down a bit so I can understand what you are suggesting ? Lol

Kind of a merge between what is desired (which yes is understood), how ZC is setup, and a way that uses the style described.

Okay,
1) you have identified that you need a "selector" that minimizes the list of items that one scrolls through.
2) Every product needs to offer the ability to select one of the combinations.
3) One can not add the product without selecting one of the options.
4) Every product is presented with the same selection of lists/options.
5) Not every product has some other alternate option to select (ie. the blue long sleeve sweatshirt already is blue and long sleeve therefore there are no attributes to select specifically about the product) (this was the part to which I was referring that not every product needs other attributes).

So, then there is sort of the implementation... One thing that could be considered is to actually have a product that is populated with all these attributes and adheres to the have to be added before some other product can be added trait, if it is selected to be removed then the product tied to it would be removed, it could be added alone, but checkout can not occur until it is balanced with the products. Not saying that is easy, but it's one way to support using an existing product.
Another, is that on every product there is a sort of "button" that is selected, and if not selected the product can not be added to the cart. The button causes a sort of popup to occur that offers the dropdown set, the selection of the final individual results in a particular entry in a database table, that database table is the one that holds all of these attributes and associations, it would/could be just like the attributes that are used for a general product, but instead are fed by some other "process". It sounds like in the "old" style that there already was a lookup of some sort, but it looked up one "column" of data instead of in groups of options. The resulting number from the one record that matches the selections made is what gets stored with the product that is added to the cart. Then anytime the cart data is to be presented, that number is looked up in the associated table and the data retrieved to "print" the information. Basically, the effect is to combine data from one table into an area that has its own set of associated data.

Could say that in a way, all this is/was described in lat9s post on the previous page, obviously in a different way and without tieing too many things together, but really until one digs into the effort/action, then some of the detail may not yet be seen. Of course I state this from my own position as I'm not entirely sure which other optional add-ons might even offer a twinkling of what is desired, but I see how a duplicate of the attribute system or a portion of it could be used to provide the associations necessary just to give the "record number" that represents the total data that you need to display, record, etc...

Make a little more sense?