This ties in with #851782: Only create menu items for product types with valid fields. The bulk add form seems to be showing any Field on the product type - for example, an Image field I have on my default product type. This obviously won't work for bulk adding unless we're supplying a single value that should be constant across every product... which I'm happy to entertain. In fact, it might be required... but let's start to tease this out.

Basically, it seems like the bulk add form should only let you choose options from fields that have a set number of options (like list fields) and are single value (i.e. you can specify on the product edit form multiple values for the field). However, thinking about it now, it might be that for fields that are single value and required but have an unlimited number of options (i.e. a text field) that we would need the user to supply the value to use and then use that on every combination of products created.

However it works out, there should be a single function that can receive a field definition as an argument and return TRUE or FALSE indicating the field is valid for bulk creation. You can then use this function here to restrict which fields you show on the form. You would also be able to use it in the issue linked above to filter out invalid menu items... i.e. check all of a product type's fields and look for at least one field returning TRUE from this function before making a menu item for it.

Comments

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Needs work

I had the same thoughts at first that certain fields should be ignored, but then I realized that some users would want to set certain fields which accept a single value such as text fields or Image fields etc and have that value be set for all of the products. It certainly would save people time down the road. That was why I didn't have the filter for those fields.

I do agree though that we need a filter function to check if the field is applicable to Bulk Product Creation. I have added in a function to do this, but for right now it is set to simply return TRUE, so that is why I am marking this as Needs Work. Are there any fields that you can think of that would not be applicable for Bulk Product Creation?

-Leighton

Anonymous’s picture

Anonymous (not verified) commented
Status: Needs work » Fixed

I've been giving this some more thought over the past few weeks and doing some experiments with fields that the user enters only 1 value for which should apply to all of the products.

For example, I created a field called 'Brand' for my Shirt product type. The user enters one value in the Brand text field and this value should be given to each product. I changed the API a bit to allow for things like this, and it works.

I also tried messing around with the Image field, but I couldn't get it to work correctly, so I added a check in the valid_field function that will stop image fields from showing up. I ended up reworking most of the API just trying to get the Image field to work, but still was hung up. I'm not giving up though, just looking into other ways to do this.

Sincerely,
Leighton Whiting

Status: Fixed » Closed (fixed)

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

sven.lauer’s picture

sven.lauer commented
Title: Filter fields on the bulk add form » Re-introducing non-list/text fields into the add-bulk form?
Status: Closed (fixed) » Active

Re-opening this to figure out what would be the best behavior.

I think ideally, the add-bulk form would have all the fields of the normal add product form, and simple takes all fields that are not list(-like) fields as constant---i.e. gives all created products the same value. One way this might be done would be to retrieve the (form_altered) product add form, and modify it in place to pull out the list(-like) fields and put them in a 'combinations'-fieldset as it is done now. On the submit side, we could calculate the combinations, put the values back into form_state and drupal_submit_form() those, instead of creating the products manually the way it is done now. This should transparently take care of all other fields without us worrying what to do with them.

Two more thoughts:
- Should all text fields get token replacements? I can see that as useful at least in textareas that have product descriptions or instructions for use, etc.
- In theory, it might be nice to find a way to generally allow the possibility to present single-value fields as multi-value fields and then use the values to create combinations---e.g. let a user enter multiple strings for a single-value string field, and then cross those with the values of a select field. This might be useful in some scenarios, though I expect that, in most cases, having a select field will be the better way to go in these cases, and thus making this option available would encourage non-optimal use.

Thoughts?

heyyo’s picture

heyyo commented

I need this feature for image field. I have clothes with different colors and size. For each color(ex: pink t-shirt) I would like to have the possibility to provide 1 picture of this pink t-shirt (or even more) and choose what sizes are available for this color.

With last dev version i don't see image field in bulk creation interface

Could I already do that ?

sven.lauer’s picture

sven.lauer commented

Nope, with the current dev version, only list and text fields show up on the bulk form.

I am working on a version where you can assign "static" values that are shared between all generated products. In your scenario, you could do one bulk create per color, then, selecting only the applicable sizes, and attach the image as "static" to all sizes in one step.

It will at least be a couple more days though before this functionality is available in the dev version, as it requires reworking quite some bit of the code and I am busy with other things, too.

At the same time, once this is in dev, I think we can start releasing alpha versions.

heyyo’s picture

heyyo commented

Really good news ! in waiting mode...

charlie-s’s picture

charlie-s commented

sven -- is any of the code that handles this in the repo?

sven.lauer’s picture

sven.lauer commented

Not yet. I've been traveling for a while, and will only get back to this after Wednesday ... check back Thu/Fri, even if everything is not up to snuff by then, I will at least post some code as a public feature branch.

jm.federico’s picture

jm.federico commented

sven,

just took this module for a spin, nice, very nice indeed.
Have you had time to work on the static values feature?

Cheers

sven.lauer’s picture

sven.lauer commented

I just pushed http://drupalcode.org/project/commerce_bpc.git/commit/a27dc0a93ec15550c2... which introduces the 'static value' feature.

The code still needs a little clean-up (& the new hooks documentation, and the new functionality tests), but it works. I'll leave this issue open at least until these things are fixed.

I have not tested this with a wide variety of "static" fields, but since those are handled completely by field attach api, everything should Just Work unless a field type module does something really weird.

Testing much appreciated, either check out the 7.x-1.x branch, or wait ~12 hours for a new dev-version to be rolled.

sven.lauer’s picture

sven.lauer commented
Title: Re-introducing non-list/text fields into the add-bulk form? » Introducing non-list fields into the add-bulk form as "static values" shared by all created products

And a quick doc update (which will go into the updated project page that I'll do over the next week):

With this commit, all fields on product types will have a(n instance) setting 'Show this field on the bulk product creation form' (default: TRUE). Disable this remove the field completely from the bulk form (otherwise, all fields except list fields will show up under 'static values'), e.g. if a field varies by variant, but must be manually supplied.

In addition, list fields (still the only ones that can create 'combinations') have a checkbox 'Treat this field as static' in the (instance) settings (default: FALSE). If checked the list field in question will not be used to create 'combinations', but rather will appear in the 'static values' field set and the selected value(s) will be shared by all created products, as for other fields.

sven.lauer’s picture

sven.lauer commented

Closing this as the hook documentations are now there and the doxygen comments for the combination-generating functions is fixed, too. Still missing tests, but at this point, that is a more general issue, for which I will create a separate task.

sven.lauer’s picture

sven.lauer commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

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

Sinan Erdem’s picture

Sinan Erdem commented
Status: Closed (fixed) » Active

I am re-opening an old issue, but this functionality cannot be found anywhere:

With this commit, all fields on product types will have a(n instance) setting 'Show this field on the bulk product creation form' (default: TRUE).

I am editing a field of a product, and only related setting is: "Show this field on the bulk product creation form"

Sinan Erdem’s picture

Sinan Erdem commented
Status: Active » Postponed

Sorry, after opening this issue, I saw this on the project page:

Known issues: Once the new submodule is activated, all taxonomy reference fields will show up in the combinations fieldset all taxonomy reference fields will show up in the combinations fieldset if they are set to be displayed in the "Add to cart" form. The instance setting allowing to force such a field to be treated as a "static field" does not show up because of #765860: drupal_alter() fails to order modules correctly in some cases.