search

staart / api

🏁🛠️ SaaS backend & API framework based on @nestjs
https://staart.js.org/api
MIT License
1.08k stars 202 forks source link

New member cannot log into the system #112

Closed cloudkompute closed 5 years ago

cloudkompute commented 5 years ago

Invite a team member member3@example.com A verification link is sent successfully and he verifies the link. He is taken to a Login page where he is asked to enter a password but he doesn't have any password so far.

Probable Solution: Create another page where he can set his "new" password.

issue-label-bot[bot] commented 5 years ago

Issue-Label Bot is automatically applying the label bug to this issue, with a confidence of 0.63. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

AnandChowdhary commented 5 years ago

Yep, this is the stupidest item in my todo list! Right now, you need to reset your password after being invited to a team, but I am going to change that so you get an email verification/account creation/join organization link in your email where you also set your password. 😄

cloudkompute commented 5 years ago

Thanks for the response. I think an answer is to redirect him to a new screen/view named Set Password screen and display an alert message that your verification is successful.

btw great work from your side!

PS: I am seeing that there are few more issues related to team. For instance, a team member who is currently an Admin is working in his own browser window and at the same time, the Owner updates his role to Basic. What should be the correct answer, I am wondering.

AnandChowdhary commented 5 years ago

That's a great suggestion, thanks @coooolers!

For the other point — Because the authorization helpers check the user's role, if the Owner updates another Admin to Basic before the Admin/Basic member makes any changes, they will see an error message saying that they don't have permission to edit any data as soon as they press "Save". When they navigate to any other page, the same will happen. Only when there is another interaction with the app will the API tell us that the user is unauthorized.

Staart UI currently does not have any member distinction, but in the next week I'm shipping that feature, so the frontend app will reflect the role as well, not just the APIs.

cloudkompute commented 5 years ago

Hello Anand @AnandChowdhary

Okay I almost got you. Kindly explain this when you said: "Only when there is another interaction with the app will the API tell us that the USER is unauthorized."

Here the USER is Owner or Admin/Basic?

I have a suggestion regarding this ... When both the users namely Admin and Owner are logged in at the same time and the Owner attempts to change the Admin's role to Basic OR attempts to delete that user, do not let the Owner to change his role or delete him by keeping a flag in the User table to identify whether a particular user is logged in or not. Flash an alert to the Owner "Can't do this operation because the Admin is logged in. Ask him to logout first" The owner can obviously ask the admin personally to logout so that he can alter his role or delete him.

Here one more point arises, namely, what should happen to the records/data created (owned) by the Admin? Probably, the answer could be that we should transfer the ownership of those records to the Owner role. It is basically a Cascade Delete issue.. obviously we cannot those records but who is going to own those records is a question.

One more point.. Create a super-admin role i.e. the owner of the SaaS application itself who can see the overall progress of his app, Also, according to me, only 3 more roles are sufficient: Admin, Manager, and User (instead of Basic etc.)

Thanks and Regards

cloudkompute commented 5 years ago

@AnandChowdhary If you have time, pl. reply to this.

by the way, I guess that which role can do what kind of work (permissions) will be hard-coded. Or, is it the Admin who is going to decide which role/person will do which work?

AnandChowdhary commented 5 years ago

Hi @coooolers, for now, the roles will be hardcoded in Staart logic for consistency between organizations:

Edit: I'll send you a more detailed reply about your previous comment soon.

cloudkompute commented 5 years ago

Hi Anand @AnandChowdhary

I agree with you that these roles should be hardcoded. But what I am seeing is that they are more (in number) than they should be .. making things little more complex. So what I suggest is that you should reduce the number of roles, probably only 3: Owner, Admin, and Basic. Rest is up to you :)

I am thinking of one more feature here. Consider that a user creates a document and his senior (another team member) is supposed to approve it before it is forwarded to other people in an app. So the Approver role should be there. This is basically a workflow functionality.

Another instance could be that one team member should be able to do CRUD operations while another member can do only 'R' (read/retrieve) operation.

A Manager of a company can view Dashboards while others cannot. From a company point of view, this is what the Manager role should be able to do. But according to what is implemented right now, a manager of a team is doing some other task i.e. CRUD team members. This leads to ambiguity.

Possibilities are endless though.. we cannot implement all.

With Regards Raman