-
Notifications
You must be signed in to change notification settings - Fork 44
Conversation
Why are we able to? $plan->features()->saveMany([
new PlanFeature(['tag' => 'posts_per_social_profile', 'name' => 'Scheduled posts per profile', 'value' => 30, 'sort_order' => 10, 'resettable_period' => 1, 'resettable_interval' => 'month'])
]); And set custom Looks weird to me to have a plan with different period that it's features. Like, you pay monthly but your features are renewed every couple months? Right now I think it won't affect this PR. But does not look OK. |
Paying subscription monthly and resetting features quaterly could be possible in some cases. I'd leave it as it is, this gives more flexibility for the features definition & usage. |
And the other real life scenario is that someone pays for the year (so we have |
Just as a side note. While it does not make sense to record feature when the user is not allowed to use it, it's good to be able to |
I don't think that is currently the way the package it's suposed to work. It does not support mettered use. You have to specify a "usage limit". One reason, among others, is that, when period has expired, it restarts the counter. You would not know how much did the subscriber use because it would be wiped and replaced with the new "1" used value. |
Yes, that's true. It counts the usage, but only for the current period and when new appears, this information is lost... |
* Refactor function * Do not check if usage has expired * Deny record if cannot use * Update docs
Right now you can record feature usage without issue and it gets renewed automatically if it
hasExpired
. But if you check it beforehand withcanUseFeature
, you will be denied usage because ithasExpired
.New logic should:
canUseFeature
since it's the subscription period that rules if you can use features.canUseFeature
beforerecordFeatureUsage
recording feature usage. Because, why should you record a feature you cannot use?