New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subs: Prevent Enterprise from creating subscription for Customer that isn't a User #2508

kirstenalarsen opened this Issue Jul 27, 2018 · 4 comments


2 participants
Copy link

kirstenalarsen commented Jul 27, 2018


An Enterprise can create a Customer without creating a User.
This means that they can then create a Subscription for a Customer that is not a User.
This means that when that subscription is turned into an order, the Customer receives an email telling them their order has been created and gives them a link to edit their order.
When they hit that link they get an 'unauthorised' page. If they then sign up (creating a User) and log in, the subscription connected with the Customer is not connected with their User, so they still can't access it.

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

Expected Behavior

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).

Actual Behaviour

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

  1. Create a new Customer from admin/customers - use a 'virgin' email that doesn't already have a User in OFN
  2. Create a Subscription for that Customer
  3. Click on the 'update order' link in order confirmation
  4. See 'unauthorised' screen
    . . you can further explore implications
  5. If you then sign up and create a User, and click the link you will still get unauthorised, as the order is not connected with your new user


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

Possible Fix

When an Enterprise is creating a Subscription, only Customers that are confirmed users are valid to be added to the Subscription

Customers that are not valid should be greyed out in the Customer dropdown

@kirstenalarsen kirstenalarsen added this to Dev Ready in Subscriptions Jul 27, 2018


This comment has been minimized.

Copy link

myriamboure commented Jul 27, 2018

I think we need to investigate different ways to solve that issue.

  • Option 1: a hub manager can't create a subscription for a customer that is not a user (what you propose above). I wouldn't vote for that option as it make life of the hub manager harder as they need to explain the user how to create an account and make sure they do it. We experienced that for private shop feature, it is pretty hard.
  • Option 2: a hub manager can add a customer in their customer list and create a subscription for that customer. At that point the system triggers an email to be sent to the customer if they are not recognized as a user, with a validation link saying something like "{HUB X] has set up a subscription for you, hopefully upon your request! For the subscription to be active, you need to validate your account + validation link". So technically we need to have "pending" subscriptions that will be activated only when the user has clicked on validation link.
  • Option 3: a hub manager can add a customer in their customer list and create a subscription for that customer. The subscription is valid as it is and the customer receives a message telling that this order is going to be made (a guest order here). IF the hub has authorized the customer to modify the order, when the user clicks on the link it is taken to a screen a bit similar to the one when you try to enter a private shop and you have not yet registered, with a message like "To access your order, you need to login. No account yet? Register." and then just like private shop, the system matches the addresses and create the account and associate the subscription to that account.
  • Other option?

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.


This comment has been minimized.

Copy link

myriamboure commented 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.


This comment has been minimized.

Copy link
Contributor Author

kirstenalarsen commented Jul 30, 2018


This comment has been minimized.

Copy link
Contributor Author

kirstenalarsen commented Aug 10, 2018

ok. So #2511 isn't doable and this is not agreed as the best solution now. A super-duper simple quick-fix solution can be achieved with #2506 and #2534.

Closing this issue and referenced for consideration in Subs v2 via Subscriptions improvements

Subscriptions automation moved this from Backlog to Closed Aug 10, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment