Individual features per subscriber

[boryn]

In some projects, I have noticed the need to individually define the features for the users.

I mean, let the user have a 'middle' plan but let them as well have feature 'x' from the 'pro' plan (for example we give them this feature for testing or we agreed they can use it).

I thought about duplicating a plan (along with its features) before creating a subscription, like $plan = Plan::findByTag('middle'); $plan = $plan->duplicate('middle-gr4ud8'); or $plan = Plan::createFromExisting('middle-gr4ud8', 'middle'); and later we can individually set the necessary features for the subscriber.

Another solution would be to create a subscription based on the unchanged plan and allow to override the features? Probably this solution would be more difficult to implement as this would involve creating another table in the database.

[bpuig]

Yes, I think it would be nice to also be able to attach features to user instead of only plan. Let me think a bit about it and the best way to do it.

Maybe the easiest and more straight forward way to solve it is making plan_features also morphable, and let them belong to plan or subscriber. That way you can attach features also to users.

The logic to attach said features would be coder's responsibility (duplicating like you or just attaching manually), everyone has it's methods and the more open is, the better.

[bpuig]

Take a look at this branch. Features can be attached to subscription via plan or just feature, it creates a replica of plan data in subscription, so subscription is not altered when plan is changed. Still work to do, but it would be awesome if someone gave it a try before releasing.

[boryn]

Great! I'm off for the weekend and will test on Monday.

BTW. Do you know the library https://github.com/spatie/laravel-permission? I wonder if the both libraries "collide" or could cooperate? Or maybe here we could use the permissions implementation for the features? Or at least have a look how they implemented it. They use Laravel gates and eg. it's possible to use directly $user->can('edit articles');. On the other hand, AFAIK they do not use the counter for feature usage.

[bpuig]

I don't think they will collide, I've used myself that package sometimes and I can't think of any function name that could collide. Mostly since all logic is done on $user->subscription() and not in $user. HasSubscriptions trait only has methods newSubscription, isSubscribedTo, subscribedPlans, activeSubscriptions and a couple relationships, that names are not in spatie's package. There will be no issue.

[bpuig]

I made a pre-release v4.0.0-alpha, note: schedules are now out of this package and in a separate package bpuig/laravel-subby-schedule as an extension.

[boryn]

H! Do we need to use doctrine/dbal in v3? Seems to be "too new" :) I have some problems with installation, including Nova dependencies.

More info here: laravel/nova-issues#3088 so it would be great to be more backwards compatible and use dbal 2.9/3. And could laravel-subby be used as well by Laravel 7 installations?

[bpuig]

Done! Packages were wrong because I just c&p from my main project. Now it's correct in alpha.1 and supports laravel 7 and 8 correctly.

[bpuig]

And could laravel-subby be used as well by Laravel 7 installations?

Issue here is that uses job batching, and that's a Laravel 8 functionality. Take a look at the package and the way schedules are processed. If you find a way that does not need batch but does the same, I'm open to suggestions.

[boryn]

I'll come back to you with more feedback tomorrow.

PS. Maybe we could set up a slack channel to discuss more easily?

[boryn]

Hi @bpuig! I tested the library a bit and the functioning of plan_subscription_features works as expected :) It's great we can have individual features per subscriber now. And that each subscriber has its own price at plan_subscriptions.

I came across some issues or enhancement suggestions which I will file in separate issues not to mix up this general thread.

[bpuig]

Perfect, I found a minor error yesterday and also tested everything. I think it's ready for release 👍
I'll close this issue now and do a release.

PS. Maybe we could set up a slack channel to discuss more easily?

To be honest, I've never used it, I've always been a solo coder so I do not know how it works. If you don't mind we can keep this here in the issue, and if someone comes in the future can find everything.

[boryn]

Ok, that's everything what I have found :) I'm off for today, will come back tomorrow with further testing and actually doing the implementation :)

IMHO these two are the most important: #28 and #30 and you can go with the v4 release 🥇