KAZOO-3669: replace reset password behaviour

[fenollp]

Notes

• needs testing
• waiting on a UI ticket: UI-1925 UI-1819
• not sure about the way to crossbar_cleanup
• why does my vm not send emailsdammit

[jamesaimonetti]

spec

[fenollp]

@jamesaimonetti On using couch_mgr:save_docs/2 instead: I don't think I can save every user's doc doc ?WH_ACCOUNTS_DB, right? Because I need to save each Doc to its own wh_doc:account_db(Doc), right?

[jamesaimonetti]

I'm confused why the view is being looked up in accounts? AFAICT you are saving the reset docs back to the account database (and loading the user doc via reset_id pulls out the account id and uses that account database). Why would cleanup occur by querying the accounts database then? Those are account docs, not user docs.

[fenollp]

You are totally right. I just have no idea how I can fetch user documents that were modified yesterday and that have ?RESET_ID ≠ undefined?

[jamesaimonetti]

You set reset_id on the user though; what happens if their doc is updated by an admin? What if they have a script that sets some property every day, bumping the pvt_modified each time (and thus never cleaning up the reset_id).

Could it simplify life if you tracked the reset attempt as its own document?

{"_id":"reset_id_256"
 ,"user_id":"user_id_32"
 ,"pvt_created":timestamp
 ,"pvt_type":"password_reset"
}

Now you can directly fetch the doc instead of using a view, and looking up the user doc is a open_cache_doc/2 call away as well.

Cleanup then becomes binding for crossbar_cleanup:binding_account() and cleanup_reset_ids(AccountDb) can query maintenance/listing_by_type with {'key', <<"password_reset">>}. I would wager this result set will typically be small enough that iterating over it and checking pvt_modified won't be overly expensive in memory/compute power.

Thoughts?

[jamesaimonetti]

@fenollp you have conflicts here now. Resolve so I can merge it!

[fenollp]

@jamesaimonetti please make sure this works on your side too