Allow project manager to add team members and set permissions at a project level

[clash99]

Allow project manager to add team members and set permissions at a project level. The will affect team member area on project dashboard #1447.

(I need to create wireframes for this and link to requirements still.)

[clash99]

OPTION ONE: Allows addition of multiple members at once and repeats ui tab pattern of resource area

Add new team member (text input):

Select new team member (from org members):

Set member permissions:

OPTION TWO: Allows addition of one new member at a time and repeats ui pattern of adding a new party

Select new team member (from org members):

Add new team member (text input) and set member permissions:

[wonderchook]

@clash I'm thinking it might be better to have a cohesive 1 page interface rather than the tabs. What about something like showing the dropdown of the members already in the org and then having the option there to "add new" and send the invite?

[clash99]

@wonderchook and @dpalomino - Added an option 2 to the wireframes above. This is more similar to the ui pattern we use when adding new parties. Take a look and let me know what you think.

[dpalomino]

Thanks a lot @clash99, the option 2 looks really good!

Just a small comment, I think we should restrict for now the "Invite new user" to the existing registered users in Cadasta platform (as we haven't implemented the user invites for non-registered users yet). Maybe we can add some text to to clarify this, like "The user has to be registered in Cadasta platform first".

[wonderchook]

@dpalomino would you rank inviting non-registered users as being more important or inviting users to a project as more important right now?

[clash99]

Here is an additional Option 3 that could be implemented before we develop the ability to invite new users. It basically removes the "Invite new user" button and adds an info box. The flow gets a little weird if the link to the members page is clicked because you are taken out of the context of the project and into the organization.

[dpalomino]

Related to this: #1448 (User Invites requirements). User Story 3 (login with mail) and User Story 4 (login with phone number) are the relevant use cases.

@dpalomino would you rank inviting non-registered users as being more important or inviting users to a project as more important right now?

Well, I think inviting the non-registered users would be more useful, but I suspect it's quite more complicated (requires the user to register first, then raise an "event" so that user will be automatically added to the project once registered and then notifications are sent). So maybe it makes sense to implement first adding the registered users (easiest and quickest) and then the possibility of inviting the non-registered users.

What do you think? Can we have a rough estimation about how difficult it'd be to implement each case? Ideally we would be implementing this in a single sprint so we release the whole feature at once, but I don't know if it's realistic.

[wonderchook]

@dpalomino can you explain a little further as to what you are hoping to be done in 1 sprint?

[dpalomino]

@dpalomino can you explain a little further as to what you are hoping to be done in 1 sprint?

Sure, sorry for not being clear. So I think we have three main tasks here:

1. Adding to the project an existing member of the org (that's already supported, it's only to implement the UI changes)
2. Adding to the project a registered user not belonging to the org
3. Adding to the project an unregistered user

So I think (1) and (2) would be in the same sprint as a minimum. And depending on the estimations re the implementation we could try to include this either in the same sprint or the sprint later for instance.

My main concern is that I'm not sure if we have something already implemented to "raise" this kind of events (like add the user xxxx@company.org to the org OrgName and notify the project manager once user has been registered), or if we need to implement the general mechanism to raise this actions when the event (i.e. user xxxx@company.org registered) occurs. I'm guessing the implementation effort would be quite different depending on this.

[wonderchook]

@dpalomino so I don't see a reason that 1 and 2 are tied to each other. We could do them separately without it being an issue.

[dpalomino]

@dpalomino so I don't see a reason that 1 and 2 are tied to each other. We could do them separately without it being an issue.

Definitely, they are different tasks. I was just suggesting that as they are small(ish) tasks, specially the first one, could be implemented together in the same sprint, but TBD. If they are developed separately then we'd go for the option 3 that @clash99 was mentioning...

[amplifi]

We should reconsider implementing 3, adding an unregistered user to a project, for security reasons.

If a project admin can add an unregistered user to a project by entering a contact method (phone, email), then have the platform automatically apply permissions to access the project after that new user completes registration, there's no way of verifying that the admin entered the correct email address or phone number, and messages can be intercepted. It would open the possibility of granting access to an unknown person, and it puts the burden solely on the project admin to identify and resolve an accidental breach of this sort. We should be very careful about allowing this level of abstraction in granting access.

[dpalomino]

Thanks @amplifi for the feedback, I think that's a good point.

I think we need to find a good balance between security vs on boarding easiness. I think the most powerful case (in terms of on boarding easiness) is the ability to invite a non-registered user to join a project, as it is just one-step process (rather than the other cases that are two and three steps processes, with the user having to register previously in the platform). However it's also true that invites for non-registered users could have some security concerns as you mentioned.

I think this is a good point for a discussion in a call or in our in-person meeting.

[oliverroick]

Duplicate of #1448. Closing