Currently this product feature can only grant one role.
This means that if I need to grant several roles with one product, users will get (I assume) multiple emails, which will seem broken to them.

Comments

brisath’s picture

brisath CreditAttribution: brisath commented

Subscribing, thanks.

joachim’s picture

joachim CreditAttribution: joachim commented

The way the data is stored at the moment means that even if we altered the UI to allow this, it would still amount to the same thing as adding 2 features, and users would still get 2 emails.

The uc_roles_products table stores the link between a product and its ability to grant a role.
It has columns for node id and role id. We could turn the rid column into a serialized array, and that should be ok as we never need to select on the rid (except for one check for duplicate data, which we'd remove anyway).
But the uc_roles_expirations table needs a rid column to select on.
So I guess we'd have to put multiple rows in, and all but the first have empty dates.
But then can the first row find the other rows when it's triggered by cron?
Would the pfid give us that? I'm not familiar with all the complexities around different SKUs per nodes and just what a pfid can represent.

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented
Version: 6.x-2.x-dev » 7.x-3.x-dev
Component: Code » Roles
Category: bug » feature

Bumping to 7.x-3.x

TR’s picture

TR CreditAttribution: TR commented
Issue summary: View changes
Status: Active » Closed (won't fix)

No one else has expressed interest in this, and no one has contributed code, so it doesn't seem to be very important. Plus, you can implement this simply by designing your roles properly - define a role with all the permissions you want to give, not with two different roles. Two roles implies to me two products since you're buying two things. You could alternative create a product kit of two products each granting one role, and then your customer would expect two e-mails since he/she bought two things. Regardless, I'm closing this because there are reasonable workarounds and there's really no demand for it. If someone wants to contribute code then we can look at including this as a feature, but we're *not* going to use serialized arrays in a table column. Let's keep the DB normalized as best we can ...