Ubercart

Sweet module idea and awesome name. Hooked you up with a user badge for all your efforts. Thanks for your contributions and forum support! It rocks.

Great module, this is going to make a few people happy including me http://www.ubercart.org/contrib/4307

Works perfect, thanks!

Cool. Thanks Ryan.

And JStarcher, glad this helps you too.

Thanks for your contribution! Though it would be nice to be able to setup power tools to any product, not just classes.

I am using D6 and Ubercart 2. I installed Power Tools. Everything is looking go, like it installed.

I have the check box for SKU disabled. But, it is still showing up under my product. I need to remove this.

As well as the List Cost and Cost boxes. All of them are showing up.

Thanks

Great module, it works exactly as I needed!!!

I think you should contribute it to drupal.org but I think this is a good candidate for be included in ubercart core!

Have you enabled the power tools enabled for your product class? here: admin/store/products/power-tools

I think I might know what is going on. I have created a Taxonomy with all my product classes. I have now created them correctly using the "create classes"

Is seems that what ever I do, when I go to node/add/product it will still show the SKU and other boxes I do not want.

Is there a way to add sub-classes under the class?

I am in the process of reading the user manual to learn more about Ubercart. I think I am going to need to know more about this product.

Thank you

I did not have uc_shipping enabled

In the product node, it shows a checkbox for shipping and weight information anyway (it must assume that a product is shippable by default).

In the power tool module, "shippable" is not one of the drop downs.

you have to go and enable uc_shippable (even though shipping checkbox appears on a product automatically) in order to remove the shipping information.

Just FYI

Thanks for the heads up.. I've posted a new version that should correct the shipping issue.

Hi,

I would like to automatically give different Alternate SKU name (under a product's adjustments) so that it combines the default SKU and the name of the option (with spaces removed).

Is there any way I can do this using Power Tools?

Thanks.

Not presently, no.

Because of the way attributes are assigned, in a completely separate step from creating and editing the product, it's not designed to work. I'd have to take a look at the attributes code to see how involved it would be to get that set up which I don't have the time to do currently or in the foreseeable near future.

If anyone is interested in developing that portion of code and submitting a patch I'd be happy to include it in the module.

Great module, thanks for contributing it. One bug seems to be that it doesn't recognize the default "product" class. And I can't add "product" as a class via "Manage classes" because it says the class already exists.

This is because the table is based on the pcid (product class id). I toyed around with making this work for non-classed products a bit tonight. There is a zip file posted in the issue queue about it (file here), but I think it kind of breaks things. Feel free to play with it and hack the code in there a bit. I think it's heading in the right direction, but I just don't have the time to put any more work into it for a while. Too many other projects that need to be finished first.

I thought that if I set the power tools for stock level to "Do not set stock levels" then the stock level would not be activated.

When I take a look at the node I use this module with, stock is activated.

1. is this module supposed to deactivate stock option?
2. if not, can you point me to the place where I can not have activate auto selected?

thanks,
chris

This module rocks, thank you!

1. setup a product class
2. setup product power tools to save node sku as
product-[nid]
3. I click "save and continue
4. click on attribute
5. select attribute
6. click submit
7. click options
8. I click on adjustments
i get "product-" not "product-123" where 123 is the nid of the node

I have to go back to the edit -> products page and hit "save" not "save and continue" for attributes to show the correct sku

Hi,
there's a bug on stock control, the test to check if automatic stock handling is missing, you should have (I've used a switch to be coherent with the whole module) :

I believe this module should be included in the Ubercart core. It simply does what most of us need to do when building our store: configure products fields. I was getting ready to do all this work by myself when I saw this module. it saves a lot of time. I believe it should by at least recommended as an important module to install with Ubercart.

Thanks a lot for this great work!
K.

Is it possible to use this module to predetermine the sell price as well? My store will be offering user-submitted files at a predetermined price, so I don't want to offer any price options at all to the person creating the product.

hello, this is exactly what i need (at least what i read in the description), thank you very much! the only thing is that i don't know how to use it. for example: i read, that power tools is in the product class settings. so i tried to create a product class how described here. unfortunally, i don't have the possibility to create a product class. i simply don't have this option at admin/store/products any help? (yes i have the rights to administer the product classes...)

I could not generate a SKU automatically with this module since none of the tokens are unique except the title of the product. I tried [nid] token but this does not work since it is null because the node has not been created yet in presave state.

I looked at the Auto SKU module (http://www.ubercart.org/contrib/4307) and decided to merge the auto sku functionality into this patch.

So now you can:
1) use [nid] token in pattern.
2) if pattern is empty it will automatically generate the sku by using $node->type . $node->nid
3) you can use PHP code to generate the pattern if the user permission is enabled to allow php code

I added a few more things to patch on comment #22.

Here is the list:
1) allow default quantity to be entered for the product as well as being overwritten on product creation (make default visible on product creation - new option)
2) allow default package quantity to be enter for a product as well as being overwritten on product creation (make it visible)
3) add defaults for product weight
4) add defaults for product dimensions

The auto sku generation from the original code 1.2 and from the patch I submitted in previous posts overwrite the sku of existing products and caused duplicated rows in uc_product_stock table for the same nid but different model/sku. I changed the code to only auto generate sku on node creation and not for existing products that had already the sku set before this module was installed.

The patch is attached. I think this seems pretty stable now that I am moving from my dev environment to production.

Please run update.php after you apply the patch.

Is it possible to add feature to hide the sale price just for one class of product?
If not could you give me a hint, what part of code should I change to implement this feature.
Should I put the following code to the uc_power_tools.install?
// sale-price Boolean on/off setting & default price
'sale-price' => array(
'description' => t('boolean'),
'type' => 'int',
'size' => 'tiny',
'not null' => FALSE,
'unsigned' => TRUE,
'default' => 0,
),
'sale-price-settings' => array(
'description' => t('default cost value'),
'type' => 'numeric',
'precision' => 15,
'scale' => 3,
'not null' => FALSE,
'default' => 0.0,
),
Are the above variables sale-price and sale-price-settings correct?
Should I just put the following code to the uc_power_tools.module?

// Handle Sale Price field.
switch ($class_settings['sale-price']) {
case 1:
$form['base']['prices']['sale-price'] = array(
'#type' => 'hidden',
'#value' => $class_settings['sale-price-settings'],
);
}
Are the above variables: sale-price-settings and sale-price correct?
Thank you in advance.

the patch provided in #24 didnt apply cleanly to the version 1.2, ive patched this manually and cleaned up some lines in there, feel free to test and check

this applies against uc_product_power_tools-6.x.1.2.tar.gz with patch -p0

gtin,

Do you have the final patched file for this (the *.module)? I tried applying the patch, but I'm getting errors.

I ran into the same problem with the auto sku and I think your patch will help. Thanks alot!

Nevermind, just saw your last post and applied the patch successfully. Will be testing it out. I'll let you know if it breaks anything.

Sweet! It works flawlessly now. The items get created correctly with [nid].

Also, don't know if this is possible, but it be nice if we can also set the stock level during product creation as well. Is there a contrib for this already? Thanks and great work!

I guess I'm doing something wrong. I apply the patch like this:

In the directory of the module (where files from uc_product_power_tools-6.x.1.2.tar.gz are extracted) i launch "patch" with these parametes:

c:\cygwin\bin\patch.exe -p0 < uc_product_power_tools_2.patch

and I get this:

The patch is the one from #26...

My first patching... what am I doing wrong? Thanks!

And by the way:
1) I would find useful to add a new token for autogenerating SKUs, something like [next-unused-id-of-class]
I understand that all of you using the [nid] do so just because you need a unique number. A counter would be cleaner, no numbers would be skipped etc...
2) I wonder why there are only the options "Show SKU field on product entry form" and "Hide SKU field and Automatically Generate from replacement pattern below". How about "Show SKU field and Automatically Generate from replacement pattern below"?

I tried the patch and got the same errors, as BayerMeister (note #30).

@BayerMeister and @LightFromArt I guess I do not know how to create a patch. I used winmerge to create the patch, Maybe somebody can give me a light on what tool to use to create patches. Do I need to install CVS? is there a standalone exe to use to create patches by doing a diff between two folders besides winmerge?

@BayerMeister I totally agree with your point number 1. When I thought about automatically creating SKUs, I would think that some kind of token that uses a counter per product class would be ideal but there are no such token available so I got the [nid] token working as a solution. I would think to do this one would have to add a new column to the powertools table to keep a counter. The read and update statements would have to use locking hints (I am not sure how to do this in my sql) to avoid concurrency of multiple users entering products at the same time. Then the column would have to be made available through a token (not sure how to do this either).

@pharoz you should be able to use the power tools module to set the default stock level and stock threshold

I am uploading the whole module to make it easier for other people instead of the patch.

Thank you Gtin, for posting a whole module. It is the best solution.
Do you know what changes could be done to hide a sale price for one class?
Or at least do you know the exact name of parameter in to use in the code?

Thanks gtin.

Will use it and comment if something goes wrong. To use the [nid] is not so bad - I don't mind.

If it was to be made cleaner I guess a new table would be needed:
Each product class would have a counter... or custom counters would be crated in a menu (counters like x y z would have tokens [powertools-counte-x]...) which would count from one. Well, I would also appreciate formating options like 3 digits left-padded with zeros ...that would have to be configured in the menu as well.

About concurrency: Well, if you used the token, it would be evaluated on commit of the product (product class). That is little time to have this problem. But it can happen. So that is something the token itself must take care of ... and that seems easy in theory (in SQL), though I'm not a SQL coder...

So in the end you would write "prod-[powertools-counte-x]" and have, say, prod-001 etc.

And what about the Attributes module? A product gets created first, attributes are assigned afterwards. There you can alter the SKU for different attribute options. So you have a Guitar in 3 colors, you append a suffix (like -a -b -c) to the generated SKU. I already read somewhere, that someone had an idea how to automate this as well. But that is nothing I need. Could be useful to concern though...

To gtin:

I tried to set the "Power Tools" Status of a class to Enabled - ok.
I set the default values and tried to save them:

...and the class ends up with the "Power Tools" Status disabled.

@BayerMeister did you run http://yoursite.com/update.php ?

The update function I added to uc_product_power_tools.install file adds a bunch of new columns for shipping. Seee below:

function uc_product_power_tools_update_1() {
$ret = array();
switch ($GLOBALS['db_type']) {
case 'mysql':
case 'mysqli':
$ret[] = update_sql("ALTER TABLE {uc_power_tools} ADD weight float unsigned NOT NULL default 0 AFTER `stock-threshold`");
$ret[] = update_sql("ALTER TABLE {uc_power_tools} ADD weight_units varchar(255) NOT NULL default 'lb'");
$ret[] = update_sql("ALTER TABLE {uc_power_tools} ADD length float unsigned NOT NULL default 0 AFTER weight_units");
$ret[] = update_sql("ALTER TABLE {uc_power_tools} ADD width float unsigned NOT NULL default 0 AFTER length");
$ret[] = update_sql("ALTER TABLE {uc_power_tools} ADD height float unsigned NOT NULL default 0 AFTER width");
$ret[] = update_sql("ALTER TABLE {uc_power_tools} ADD length_units varchar(255) NOT NULL default 'in' AFTER height");
break;
case 'pgsql':
db_add_column($ret, 'uc_power_tools', 'weight', 'float unsigned', array('not null' => TRUE, 'default' => 0));
db_add_column($ret, 'uc_power_tools', 'weight_units', 'varchar(255)', array('not null' => TRUE, 'default' => 'lb'));
db_add_column($ret, 'uc_power_tools', 'length', 'float unsigned', array('not null' => TRUE, 'default' => 0));
db_add_column($ret, 'uc_power_tools', 'width', 'float unsigned', array('not null' => TRUE, 'default' => 0));
db_add_column($ret, 'uc_power_tools', 'height', 'float unsigned', array('not null' => TRUE, 'default' => 0));
db_add_column($ret, 'uc_power_tools', 'length_units', 'varchar(255)', array('not null' => TRUE, 'default' => 'in'));
break;
}
return $ret;
}

By the way, you should correct the bug I reported on #18 comment.

Seems like 6.x-1.3 from #32 is ok with those that have updated. Is this tested enough to be official?

Yes, my fault, I didn't run the update.php - it's all ok now. Many, may thanks for your support.

And here's another question: I use php code to generate the SKU, run queries etc. Can I somehow use the values that were filled in the form?

Example: The new product entered is a "piano" or a "guitar" (the catalog taxonomy). Let's say I want to prefix pianos with a "PIA" and guitars with a "GTR".

Can I access this values in the code already? (I have no idea if it is accessible at the moment of this php code running, have no idea how to address these values.) If yes, pleas give an example of how to access the Catalog selection value (might be an array as multi-choice is allowed in catalog).

Using the module from #32 i wrote a simple PHP script for auto SKU generation (the "Pattern for the SKU").
I wanted the Catalog category to make a 2-digit prefix and a serial 4-digit suffix starting from 0001. I knew I would not use the "description" field from the term_data table (that is the description of a term in the catalog category) so I used it to store the prefix there.
First the script gets the prefix from the selected term(s) in catalog-category, looks up SKUs with this prefix, takes the last one and creates a new SKU with an incremented value.

There is a lot to fix:
First this assumes that products will not be deleted in future. If you deleted the last product and created another one the same SKU could be generated which I don't want. I guess I won't be deleting them anyway. A nice version should keep a counter for each prefix and never forget what the next number is going to be.
The same place where the counter would be the prefix itself should be stored. A table mapping these values to taxonomy's "vid" would do. This way the description of a term would not have to be abused.
At the point in code marked with *** I used to have an inner join with the "node" table and tested the "type" (the product class).

Warning and help request:
I have next to no experience in PHP, trivial errors possible - please comment on them
I have no practice in logging in Drupal or Ãœbercart - tell me how to do it right. It works like this to a certain extent. It would be nice to hinder the product from creation if any errors occur during SKU generation.

Yet another idea: Could this module be altered to support pre-setting Categories? I know they are user created... makes it a bit more complicated. There are some categories that would deserve this. If you have for instance a category that divides products into those which can be acquired from suppliers and those which are there for historic reasons (accessible by direct URL, but not visible in catalog anymore) you want newly entered products to be in the first set by default.

I think I just found a bug.

If the power tools option to set a default stock level is on, and you go edit the product, then change the stock level, it works. When you go back in and just edit the product's description, it changes the stock level back to your default.

I noticed this when I had the out of stock notification module on and it keeps saying the item is available even though I set the stock to 0. It occured to me that it only happens when I had to go in and edit the product's description.

Any thoughts?

I wonder if the fix on #18 is for this bug you reported. I did not understand what #18 is fixing that is why I did not include in my patch. Why don't you try the change in comment #18 and let us know if it fixes your problem?
If it doesn't then I may come with a fix since this will definitely affect my site as well.

Regarding comment #25, is that an approach that is safe/might work? Has that feature already been added to 1.3?

Not sure whether to direct energy in this direction or if its been done.

This module really deserves more of an issue queue and repository than just the one forum thread

I would love for it to be in Drupal contrib. Any chance we can make that happen?

Happy to help if you need it.

Thanks for all the work on this guys!

I'm working on getting it into the drupal.org repository currently. I would have been more proactive in the support here, but since I don't get notifications when this thread is updated it's been kind of an out of sight, out of mind situation.

EDIT: My CVS account has been approved. I'm just going to go through quickly and do a little cleanup of the code and make a couple small changes and this will be up on the drupal.org repository following that.. most likely by the end of the day, but certainly by the weekend -- depends on when I have a chance to really take a look at things.

gtin,

I found out the issue. The subroutine to handle stock needed to be placed within the auto sku routine since it is only activated when a new product is created.

Here is the code that was changed on your module. Begins at line 179:

I've tested it and it is working properly now. Not bad for my first time at php!

pharoz,

Is that based on the zip file that gtin posted? I'd like to get as much of these issues all rolled into one to get the most recently revised/bugfixed version put together before I do the initial commit to cvs on drupal.org.

Thanks!

Oh, and yes... nicely done for your first time at php!

There's a little more to it than that, because it needs to be stored in the database to work properly.. but, although I'm mighty short on time this week, I'll get that put into the final version I will be putting up on drupal.org soon... only reason it wasn't there to begin with is that it never really occurred to me that people might want to hide that field as well.

tcindel, that's correct. It's from the zip that gtin posted.

Also, from an issue I mentioned in post #32, I was referring to exposing the stock field in the initial product creation page so I can enter it there vs having it automatically entered. I know you can define default stock quantity, but you will have to go in later and change it to the actual on-hand quantity later AFTER creating the product, which is an additional 2-3 steps. Know what I mean? Anyways, AWESOME module and I hope this makes it into core!

Got it.. I'll take a closer look at that when I've got a little more free time. Just finished doing some code clean up, added the ability to preset the sell price and hide that field, and incorporated your changes.

The module is now available on drupal.org: http://www.drupal.org/project/uc_product_power_tools

Thanks for all the effort you've all put into this so far. Start using the issue queue over at d.o for any further updates/bugs/etc..

By the time most people read this it shouldn't be an issue, but there is a major bug in the first version I commit to the repository, so don't install from drupal.org unless it is version 1.8 or higher; otherwise none of your settings will save and it just won't work as expected!