U - Move subscription management out of the wiki

[peterbe]

Summary Thanks to https://github.com/mdn/kuma/issues/6322 the Edit Profile page stays on the read-only site (no wiki. in the URL) and it uses the read-only site header & footer.

However, /en-US/payments/recurring/management is still on the Wiki.

Acceptance Criteria

• [x] subscription management page reactified
• [x] terms page reactified

Rationale You don't want to, or should have to, see the Wiki (header or domain) if all you're doing is setting up and managing a subscription.

Audience Everyone

Proposal Do whatever we do in https://github.com/mdn/kuma/issues/6322 to the /$locale/payments/recurring/management page. And other /$locale/payments/* pages such as the terms page.

Additional context Hmm

[mindy]

@malqinneh Do you know where I can find the original design for this page? Wondering if there are any differences between what we currently have on production and the intended design.

[malqinneh]

Spoke to Mindy, basically we grandfathered the current [MDN subscription management] page (screenshot above) as is, with all existing functionality/UI.

We have a couple of options if we want to optimize the cancellation experience:

1) not taking users to a separate page to manage their subscription 2) streamline content/information on this page

[mindy]

I think given the time constraints (this was slated to be done for Delta), I vote for option 2.

I also wanted to clarify that I didn't want to take too much of your time, Mustafa! I thought there could be some small improvements that we could weasel in while working on the main task of this ticket.

[malqinneh]

Of course! I think we can clean it up. Checking to see if we're currently using that page to manage any other membership type on MDN. The current copy makes it seem like we are. Want to make sure we don't remove relevant copy.

[peterbe]

If we do bother to change the functionality (other than just moving it from the Wiki's jinja templates to React) the only functional thing I'd like to see is that we don't format the amount like "$0.0" :) Which brings to mind; how the heck did you manage to set up a subscription of $0 @mindy ??

[malqinneh]

@mindy let me know if the above looks feasible (without adding too much work). Don't mind the styling too much, we can keep whatever style is in production.

[malqinneh]

If we do bother to change the functionality (other than just moving it from the Wiki's jinja templates to React) the only functional thing I'd like to see is that we don't format the amount like "$0.0" :)

Grandfathered from the past experiment, there will be users who "subscribed" with $2 or $6. Confirmed with @atopal that we will leave all current subscription amounts as is.

[peterbe]

Perhaps also replace the "Back to profile" with a link to the Subscription landing page?

[malqinneh]

Perhaps also replace the "Back to profile" with a link to the Subscription landing page?

The user would have come to this page from their user profile (think the initial UX provides a way for users to return back from where they came from).

Why would the user want to go to the subscription landing page at the point they are at?

[mindy]

This looks so much better and feasible-- thanks Mustafa!

The user would have come to this page from their user profile (think the initial UX provides a way for users to return back from where they came from).

☝️There are currently three ways to get to this page:

• Edit user profile, as you already know (https://wiki.developer.allizom.org/en-US/profiles/[user]/edit)
• Payments landing page, question 12 (https://developer.allizom.org/en-US/payments)
• Payments thank you page (https://developer.allizom.org/en-US/payments/thank-you)

[malqinneh]

There are currently three ways to get to this page:

* Edit user profile, as you already know ([https://wiki.developer.allizom.org/en-US/profiles/[user]/edit](https://wiki.developer.allizom.org/en-US/profiles/%5Buser%5D/edit))

* Payments landing page, question 12 (https://developer.allizom.org/en-US/payments)

* Payments thank you page (https://developer.allizom.org/en-US/payments/thank-you)

Thank you for clarifying @mindy! Forgot about linking from [Payment landing] and [Thank you] page(s).

In that case, if we implement the changes I suggested, can we also remove the button that takes you back to [Profile]?

[mindy]

In that case, if we implement the changes I suggested, can we also remove the button that takes you back to [Profile]?

Sounds good to me! Thank you!

[mindy]

@atopal @tobinmori Any objections to changing the url from " /payments/recurring/management" to "/payments/management" to be consistent with the rest of the payments urls?

[atopal]

No, that sounds good to me, @mindy

[peterbe]

Any objections to changing the url from " /payments/recurring/management" to "/payments/management" to be consistent with the rest of the payments urls?

Might still be a good idea to leave a 301 redirect behind in kuma/payments/urls.py

[peterbe]

@tobinmori I un-assigned @mindy from this issues since it's a user story. Devs should be assigned to tasks.

[chinikes]

@atopal, @peterbe , @mindy, @tobinmori - With all tasks done, is this user story good as done?

[peterbe]

With all tasks done, is this user story good as done?

I can never remember the correct protocol. But isn't a sprint demo first and them @atopal closes the user story?

[chinikes]

No, the user story can always be reviewed and closed in the middle of the sprint. In the retro, we talked about reviewing the user stories earlier in the sprint for a faster feedback from the PO

[peterbe]

So how about this, Mindy, Kadir, and myself meet up on Zoom and demo the features of it if Kadir is happy with it, he closes the user story. Plan? Invite?

[chinikes]

Kadir should be able to review when he's around on Monday. Any process that works for the team is all good.

[atopal]

That sounds good to me @peterbe I'm around after the bug triage today, does that work for you?