Permissions for uc_attribute, uc_stock

I'm not sure we should switch up access to various items in the minor release, unfortunately. I'll definitely consider these changes and others for D6 and beyond, but I wouldn't want to have a whole host of folks update and get thrown off by all the disappearing pages. Even if we mention it, it's likely a majority of folks won't update permissions or expect to have to.

I know that sucks for folks on D5, but my best recommendation would just be to keep your patches handy during updates as long as you're on D5.

I'm postponing this until we get the D6 work into Drupal CVS for issues.

+1

To get this into core, can't we include an update in install.php that would automatically add the new permissions to any user belonging to a role that had the old permissions?

Cheers,

Jon Antoine
www.antoinesolutions.com
Open source development documentation

I agree with Ryan that this should go into the D6 version. That means that these patches need to be rerolled because a lot of changes to the menu hooks were made.

Is there a reason that the 'administer product options' permission isn't used on the option pages in the admin section? I only see it used on the product tab.

The thing about splitting up the attribute permissions is that they are not independent. Being able to change a product's attributes means that you can remove options and adjustments, so someone with only that permission should be able to access those other pages as well. This patch takes care of that, and also has a permission for changing the global attribute data.

Take a look at #373651: Confusion involving attributes and product kits as well. It's only somewhat related since it involves the access callbacks, but it might help knowing about it when applying the patch.

It's for 6.x. I wanted to find an excuse not to port it to D5, but I couldn't. ;) So here it is.

This patch failed to apply because it looks like Lyle has since made a change to the prior uc_attribute_product_attribute_access() to make sure product kits don't get an attribute tab.

Rollin', rollin', rollin'....

Applied cleanly, looks good. I can still access those tabs, so I'm assuming it's working as expected. : )

Great.

Committed.

Does the patch in #8 work?

Here ya go. BTW, there was a typo in that last patch that I didn't notice 'til I started testing stuff. Since we released a beta today, I have included an update function in the 2.x branch to address this problem. Clear those caches!

Alright. Committed both patches.

Oh snap. I've been doing some custom hacks to get this to work. Noticed the change in -beta5. Thanks guys.

#395590: Can not administer Attribute is a duplicate.

FWIW, it looks like my 2.x patch to fix the typos didn't make it into the beta. You should get this patch and run update.php or the permission is broken.

For ubercart market place, I'm wondering if it can be setup so sellers get email notification when their stock level is below the threshold.

Thanks. I'll do that.

Not sure I'm doing this correctly.
patch -i ~/279611.attribute_perms.2.x.patch -o uc_attribute.install
patching file uc_attribute.install
Hunk #1 FAILED at 617.
1 out of 1 hunk FAILED -- saving rejects to file uc_attribute.install.rej

Did I need to apply the other patch first? am I applying the patches incorrectly?

While this is the first step in expanding on the privileges for uc_stock and uc_attributes, I believe it needs to go a step further (especially if we want to use this for uc_marketplace).

Say you have two sellers in your store. You've set them up in a role with "Create Product" and "Edit Own Product" permissions only. You've also given them "Edit Product Attributes" and "Edit Product Options" .

Now as I understand it with this patch, these sellers will be able to add existing attributes and options to their products ...but if the store administrator hasn't included all the pre-existing attributes/options that a seller might need, he'll have to contact the site administrator to create them for him, so that he can add them to his product.

Otherwise, you'll have to give both sellers, "administer attributes" permission in which case, they can ruin each others options by editing/removing existing options or attributes.

Ideally attributes will be linked to the users account somehow and permissions will have to be able to distinguish between a user who can edit his own products, attributes and options and a user who can edit all products, attributes and options. User who can only Edit his own products, should be able to create/edit his own attribute sets and options sets, and add them to his products. Then only global administrators who can "edit any products", should be also able to edit them.

Globally created attributes and options, should be available to everyone. You should have an option to keep the attribute/option sets privately to only your user.

Let me know if I need to clarify.

I don't think you need to clarify, but this does represent a significant departure from the way the system currently works. I recommend starting a new feature request so discussion doesn't get lost in this closed issue.

Feature request posted here: http://drupal.org/node/441516

I think this is something that should work it's way into Ubercart shortly after 2.x is released.

Ubercart 3.x Feature Request Survey anyone?