User Story 1: When the application has been set up and is being run for the first time, the user should be able to set up his account.

• Once the fresh instance of the application has been deployed on the server, there is no data in the system. And when the user tries to load the base URL (for example, kb.quicklabs.in), he is asked to set up the account by providing a full name, email, and password.
• Since there is no feature to add new team members, this is the only time the user does a sign-up. And this user is the only user who will keep using this for a lifetime. We are not going to add multiple users with a complex role-based permission structure. Just one user for a lifetime who has admin access.
• Since there is no integration with a third-party email service, this means we have neither any way to identify the user email nor do we have a way to set up the password again if the user forgets the password. This limitation is handled by two assumptions.
• First, we know that our user is a technical person, and he is setting up the KB from the open-source instance, and he will be the one using it for a lifetime; therefore, we are assuming that the person who is setting up the account knows what he is doing, and we do not need to identify his email since he is going to deploy on his own servers.
• Second, the user might forget their password after setting up the account. We are assuming they will be smart enough to save their password in some sort of wallet to recover it if they forget it. In addition to this assumption, we are adding another layer of features to help them in this case, i.e., generating a recovery code for them. When a new account is being registered, a new account recovery code is generated for them, which they are explicitly asked to store in their wallet to recover their account if they get locked out of it. If both of these things fail, we are counting on the other assumption that the user is a technical person, and he can recover his account by resetting the password in the database itself. The recovery code is dynamically generated for each server instance so that no two recovery codes are the same for two different deployments.
• Once a user is logged in a browser, he remains logged in until he specifically logs out.
• The designs of first run and login flow is here https://designs.quicklabs.in/quick-kb/
• We are also asking the user to tell us the name of the knowledge base that is used in the header, among other places.
• Once the user has signed up and the account is set up, then the workspace page becomes the landing page, i.e., when the user enters kb.quicklabs.in in the browser, he lands on the Workspaces list.

User story 2: The user should be able to log in after setting up his account.

• When a new instance is created and hosted on a URL and the user has finished the first run and completed setting up his account, he should be able to log in with the email and password he set up previously.
• Designs are here: https://designs.quicklabs.in/quick-kb/firstrun/login/

User story 3: The user should be able to reset the password if he has forgotten it.

• Since we are not integrating any email service, we are counting on the user to store his password in a safe wallet. But if he still forgets it, we are counting on the user that he has to use a recovery code to reset his password. The recovery code was generated when the user signed up and since we asked him to store it, we hope the user has stored it somewhere. If the user has not stored a recovery code also, we are counting on him to use his development skills and recover this account from the database SQL. We can not do much if all 3 options fail.
• If the user has saved up a recovery code, the user should be able to set his password again by using it.
• User should be forced to log in again after user resets password. We want to confirm that the user remembers the password once it has been reset.
• Designs are here: https://designs.quicklabs.in/quick-kb/firstrun/forgot-password/