Refactor session logic to anonymous user accounts

[aaronjudd]

Current Session behaviour:

new session
return all orders for sessionId  (0)
places an order as a guest - we now have 1 session order
login as user - place order - we now have 2 session order returned (same session)
logout as user - we now have 1 session order returned
clear session - > we now have 0 orders
login as user -> we now have 1 user order
logout as user -> we now have 0 orders
place order as guest -> we now have 1 guest (session) order

the problem is.. what should the logic be when the same session exists. Creating a new session after an order is placed should resolve this (but may have some complications)

[aaronjudd]

@mikemurray I'm looking into using anonymous user accounts, rather than maintaining the "sessions" logic. I don't remember my logic for not doing this from the get go, but I assume I felt it would be both a maintenance and performance issue. (ie: creating a lot churn on the users collection). The upside is that we'd only every have to deal with the users collection, and can refactor easily broken and complex bits that've been bothersome for a while - (caused mainly I think in an attempt to avoid this approach). This will complete remove sessions from cart handling.

This means every user would start as logged in to a unique anonymous account, unless they have already logged in as regular user. This would change the accounts UI flow in #348 reaction-accounts.

Here's how I'm thinking the accounts workflow could work.

UIX

• If no "owner" role -> display a modal for create admin
• handling from confirmation, or remote creation:
  • if shop "owner" role, but no password set, display "set password"
  • if password is set, but is first login, display reset password
• If not logged in as user -> create anonymous user account
• If logged in as user -> display normal accounts flow
• if logged out as user -> display normal login sequence
• If logged in as anonymous -> dont display
  • {{currentUser}} overriden to display login if anonymous user
  • allow anonymous to login to existing account
  • copy cart items to new/existing Account and Cart on merge
• handling of 'reset password' on create/login for anonymous

Merge

• if you have two anonymous user accounts ( 1 ) and ( 2 ), on two devices and login on ( 1 )
  • ( 1 ) logins into a third ( 3 ) account (create new or login)
  • Cart from ( 1 ) is extended into ( 3 )' Cart
  • Account from ( 1 ) is extended into ( 3 )'s Account
  • cart from ( 2 ) is still anonymous
  • ( 2 ) login to ( 3 ), cart is now (1,2,3)
  • reactively reloads cart (checkout, login,etc)
  • ( 1, 2 ) are abandoned users - needs cleanup
  • ( 3 ) logs out and a new anonymous user is created ( 4 )
  • ( 4 ) adds some new items to cart, abandons it
  • reactively add abandon cart tooling for ( 4 )
  • where cart is x age, and state is not in progress - hello "clippy cart"
• automate cleanup of anonymous accounts
  • There are quite a few meteor options for job handling.
  • thus could use a server scheduler to have a filtered cleanup job
  • could do this in publications - would be extra churn on the db/server though it probably wouldn't be noticeable for a while - could be optional default, with scheduler as an option for optimization.

@queso appreciate your thoughts on this as well...

[boboci9]

I think this is linked to this issue but when you log in the system with a user and then create an order then log out the completed page is still there with multiple orders, some of which weren't made with the user who was last logged in (but they shouldn't be shown if noone is logged in) The list of the orders on the completed page are selected by sessionId I think, and not by user because the list contains orders which were not made by the current user.

[newsiberian]

Hi. As far as I understand, current logic of sessions flow may be illustrated by this diagram:

So, as you could see, we got a problem here. I've just started to think how to fix that... Maybe someone has ideas on this case?

[newsiberian]

Hello, here what we have: We can try to cut out all ReactionCore.sessionId global use cases, by passing real sessionId to this methods. And maybe remove the session collection completely as next step. As you can see, there is a one place - ReactionCore.MethodHooks.after("cart/submitPayment") - where we can't pass browser's sessionId directly. But we can do it from cart/submitPayment, so maybe we don't need this hook at all? Could we, for example, add this functionality to some new method, witch will be called after cart/submitPayment? Or maybe we could add this snippet to the end of cart/submitPayment? @aaronjudd, I will be waiting for your decision here.

UPD (02.01): problem with hook solved.