Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Subs: Prevent Enterprise from creating subscription for Customer that isn't a User #2508
An Enterprise can create a Customer without creating a User.
This situation of creating orders / future proxy orders for a non-user / unconfirmed user is undermining the logic of the email confirmation work. While we still allow for guest users, it does not make sense to do so for a subscription.
Allowing the Enterprise to instigate User creation from Admin (e.g. when creating a Customer) could be a longer term solution to this, but would require full inception and is not part of Subscription V1
In the meantime we can prevent the Enterprise from creating an invalid subscription by only allowing creation of Subscriptions for existing / confirmed users
Only confirmed Users can have Subscriptions created. Therefore when they receive order confirmation / amendment emails, they will be able to login and access those orders (pending #2506).
New Customers that don't have confirmed Users can have subscriptions created. This causes multiple problems, including undermining email confirmation, sending them information that they cannot act upon, and failing to connect their subscription with their User even after it is created.
Steps to Reproduce
Testing Subscriptions as a person new to it, got completely tangled. Potentially very off-putting to Subscription beta testers
s3 - with sufficient user guide, assuming people read it, enterprises can ensure that Subscriptions for Customers with no User are not created. And/or, they can delete and recreate Subs once the Customer has created a User. But it is very easy to make this mistake and the implications (delete and recreate Sub, or losing an irritated customer) are reasonably large
When an Enterprise is creating a Subscription, only Customers that are confirmed users are valid to be added to the Subscription
I think we need to investigate different ways to solve that issue.
I would vote either for option 2 or 3. For me option 2 makes more sense as a subscription in itself is a contract so forcing registered account for a subscription (know user identity) makes sense to me.
referenced this issue
Jul 27, 2018
So @sstead proposal here #2506 corresponds to option 2. If we all agree that's what we want to do I suggest we close that issue and keep the other one, but specify it a bit more clearly, especially what message exactly get sent when and what it triggers on system side at which moment. This is definitely a bug for release one of subs to work, so we need to fix it. Meanwhile I put the other issue in "analysis and design" in the bug management board so that we know when it can go to dev ready.
referenced this issue
Jul 30, 2018
hmmm. My issue here is with the line between bugs / issues preventing release of v1 and extension of the feature set. I am conscious of the tendency to scope-creep and never be able to tick the box on v1. I think that option 2 would be the preferred one because i think that having a Subscription created in the system SHOULD require a User to be created. It doesn’t make sense to use a ‘guest’ for something that is a recurring contract. To create the subscription as a contract requires at minimum confirmation of an email surely But to implement 2 requires creation of some new actions and interfaces, incepting the flow etc, and working out a ‘pending’ subscription - which to my understanding is a new ‘state’ that is not currently supported in the already quite complex subscriptions mechanism I don’t see it happening anytime soon and I want to release v1. Hence my preference for Option 1 now. I agree it makes life harder for Hub Manager than 2 or 3, but right now, for people who really really want to use subscriptions, it’s much better than the mess that occurs if you create a subscription for an unverified customer OR relying on Customers to tell you when they have signed up . . although . . I have just realised that there is still a missing link because you still need customers to do this so you can add them to your customer list. Which means that we either need to a) have something in the Add Customer interface that tells you if your are trying to add someone who is not a user b) fix / clean-up the problem about linking a Subscription - and any orders - created for a guest with a User that is created AFTER the Customer and Subscription? If we viewed that as a BUG and fixed that, then might the whole problem would actually go away? If we did INSTEAD - #2511 ensure that any Order or Subscription for a Customer was linked with the User for that email, regardless of WHEN the subscription and order were created - AND made #2506 a prompt to login OR sign-up . . then the problem might be solved . . we could leave the current (not ideal) state as is where subscriptions and orders can exist for unconfirmed customers, but if they want to view or make changes to it they need to sign-up / login? I have created a new issue for #2511 to investigate how doable that is, and added comment in #2506…
On 27 Jul 2018, at 10:05 PM, Myriam ***@***.***> wrote: So @sstead <https://github.com/sstead> proposal here #2506 <#2506> corresponds to option 2. If we all agree that's what we want to do I suggest we close that issue and keep the other one, but specify it a bit more clearly, especially what message exactly get sent when and what it triggers on system side at which moment. This is definitely a bug for release one of subs to work, so we need to fix it. Meanwhile I put the other issue in "analysis and design" in the bug management board so that we know when it can go to dev ready. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2508 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACxryJg-O7w-tIilmxxdfOiaHdpMnWiOks5uKwHtgaJpZM4Vi-ZK>.