fix(customer-portal): show downloadables to members via benefit grants#12393
fix(customer-portal): show downloadables to members via benefit grants#12393pieterbeulque wants to merge 1 commit into
Conversation
Members in the customer portal could not see downloadables. The repository filtered by `Downloadable.member_id == member.id`, but a downloadable row is unique per (customer, file, benefit) and shared across a customer's members, so its member_id can only ever reference one of them. On seat-based products the same file/benefit is granted to several members, they collide on that one row, and only the first-granted member gets attributed — everyone else sees nothing. A downloadables benefit defines its files at the benefit level, so every member holding an active grant for that benefit is entitled to the same files. Gate member visibility on the member's benefit grants (the source of truth for per-member entitlement, which already works) instead of on the shared Downloadable.member_id column. This also fixes legacy rows that never had member_id backfilled. No migration required.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
OpenAPI ChangesNo changes detected in the OpenAPI schema. |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
|
Preview Environment |
psincraian
left a comment
psincraian
left a comment
There was a problem hiding this comment.
I would love to discuss this approach. I thought I removed the uniqueness of customer_id in every benefit type, but seems I was wrong.
My main idea is that benefits are member aware mainly, as we grant benefits for each member. For me the downloadable should follow the same pattern as the others, so we should replace the uniqueness to be member and benefit_id aware only.
|
I'm fine with that too. What are the steps involved in that approach then? I imagine it'll need a backfill? |
|
that will become more a burden, yes 🥲 as it's a shitty thing that I forget, I can fix it. The idea would be to remove the customer uniqueness and add a member uniqueness. Then do a backfill of missing downloads (looping through customer members) |
3 participants
I believe this was never finished, and I think it makes more sense to remove
member_idfrom downloadables instead of duplicating a downloadables row per member, whereas for e.g. license keys it was required to generate a license key per member.Generated description
Members in the customer portal could not see downloadables. The repository
filtered by
Downloadable.member_id == member.id, but a downloadable row isunique per (customer, file, benefit) and shared across a customer's members,
so its member_id can only ever reference one of them. On seat-based products
the same file/benefit is granted to several members, they collide on that one
row, and only the first-granted member gets attributed — everyone else sees
nothing.
A downloadables benefit defines its files at the benefit level, so every
member holding an active grant for that benefit is entitled to the same files.
Gate member visibility on the member's benefit grants (the source of truth for
per-member entitlement, which already works) instead of on the shared
Downloadable.member_id column. This also fixes legacy rows that never had
member_id backfilled. No migration required.
Summary by cubic
Fixes member visibility of downloadables in the customer portal by checking active benefit grants instead of Downloadable.member_id. Restores access for seat-based products and legacy rows without member_id.
Written for commit d2f1057. Summary will update on new commits.