role inheritance based on product.

This would be useful for me as well. Other sites might have membership for organizations vs. individual donors, for instance.

That feature would also be needed for the site I'm working on.

I quickly checked and it seems to be doable, although it needs to be carefully specified to avoid the security issue mentionned above.

I was thinking of adding a field with the inherited role id in the ec_product record, but this is a quick think, and i'll think about it twice after studying deeper the eCommerce module internals.

the inherited roles available for products would be the ones we currently define in the store settings, but the checkbox list could then be displayed and customized for each product.

For security, I'm afraid a flexible & secure solution would require work on users with one role being able/unable to grant other users roles, and i'm not sure this is managed already, at least by the core itself.

we can also simply restrict creation of products with role inheritance to users having the "administer users" permission checked. but then a full store could not be managed by someone who does not have this feature (only for the inherited role type of product however). That's fine with sites with a single store, but may be not for users store provided by the "stored" module.

May be one of the eCommerce gurus could guide us for implementing this feature ? Or may be it is already being worked on and we only have to wait :)

i've started to implement the roles per product feature.

what was done is moving the drupal variables storing assigned roles into the ec_product & ec_transaction_product tables.

i've added an on_payment_roles field on both table, and quickly hacked the product.module to handle this. roles can be checked on products creation (if you have the administer users permission), and the content of the variables is stored in the added db field, and can be loaded back into cron hook and transaction management to apply the roles specified.

the roles are stored in a serialized array varchar field, so this is a quick hack, despite the field adds in tables. i'm not releasing any patch as i still need to hack the other modules so they take the roles infos in the database, and not in the variable.

before hacking the other modules (store,payment), i wanted to get the input of ecommerce developers about this feature and its implementation. other way to make this would be to add an ec_product_roles table, and storing the roles assignments in this table, indexed by product/transaction ids. this might be a preferred way and cleaner way instead of my first hack.

would this feature be added to the official code once complete ? and in this case, is the hack with serialized array correct enough or should i implement with the dedicated table way ?

i think i've managed to get the things work. i've finally decided to quick hack the store module to handle per product role inheritance to see the feature in action.

that seems to work well, even after a quick check of role deletion upon transaction expiration. i'll roll a patch tomorrow if someone wants to give it a try, and may check if a patch for 4.6 is doable.

after thinking about the whole role ineritance process, i realised that there's no check on multiple transaction before a user is removed from a role. for example, a user buy a product that give the goldmember role. this transaction expires on october 1st. the same user buy another recurring payment product, that also gives the goldmember role, and expires november 1st. the user will be removed goldmember role by the first transaction expiration. that's the case for both initial role inheritance feature (unless i missed the checks in the code), and for the hack i've done. code for check is not trivial, but i'll look at how to do this as this might help avoiding troubles :)

i've also thinked at implementing the role by product feature with a dedicated db table (the ec_product_roles mentionned earlier). that might lead to simpler code, untouched ec_product & ec_transaction_product, and code-only patch. i'll double check.

Here's the patch to store.module and product.module to enable per product role inheritance, as described above.

you also have to run this in mysql to add on_payment_roles fields to ec_product and ec_transaction_product :

alter table ec_product add on_payment_roles varchar(128) not null default '';
alter table ec_transaction_product add on_payment_roles varchar(128) not null default '';

the thing is working, but i'm not sure the role are removed upon product expiration. i had to force the product expiration to test, but i'll have to look closer.

i've also removed the restriction to give roles only for recurring payments. every product can have roles assigned, and user buying will be assigned the roles upon order (no auto removal in that case of course).
don't know if it's useful or if it has to be removed, let me know.

i've found several problem with object/array in the code. sometimes object are used, sometimes arrays, and there's some mix on this where object are accessed as arrays and arrays accessed as objects. this explains some of the problems i have with out of the box head ecommerce module (transaction view not displaying for example). i'll look at this closer, unless someone is already fixing these.

let me know if the patch works :)

moved this to code needs review.

please review this and let me know if this can be added with current implementation (added fields to ec_product/ec_transaction_product), or if implementing using a dedicated table would be better.

i'll post a new patch in 1/2 days after reviewing it myself with full test cycle (role removal on product expiration).

thanks

Interesting idea. Have you considered using the good ol' nodeapi hook to add this feature?

Regarding the object/array problem. If you could take a look at this it'd be much appreciated. I'd prefer to use objects where possible.

> Interesting idea. Have you considered using the good ol' nodeapi hook to add this feature?

the good ol'nodeapi is just brand new for me :)

i'm currently studying other/official way to implement this, as i feel far from confident in the present hack,
made essentially to start putting hands in drupal/ecommerce code. distinct table with roles feature added through api should be the way to go. and there's no doubt the good old nodeapi might soon by a friend of mine :p i'll keep the work going until something "drupally correct" comes out.

> Regarding the object/array problem. If you could take a look at this it'd be much appreciated. I'd prefer to use objects where possible.

as far as i'm concerned, i prefer objects too. i'll be working on ecommerce head in the next days (working on a preorder system, http://drupal.org/node/31543), so i'll try to come up with a patch to standardized the object/array problem. this will take about the same time than the debug session needed with issue related to this anyway.

thanks for your comment

found bug in role removal, so i'm moving this to code needs work.

don't bother using the patch unless you want to see what it looks like.

current implementation is not the way to go, so i'll re-work this after reading api's docs carefully, and will double check the array<->object convertions in the meantime :)

in case someone is reading, i'm still working on this.

plan is to come up with a distinct product roles module, and to provide all features through standard API, as suggested by Matt Westgate. no timeline given, but i think it should be available soon as preliminary code is almost working.

refer to sammys ec_recurring