Taiga-front: Adding existing members to a project

[mrichar1]

Currently, when adding new members to a team, you only get to add based on full email address.

It would be nice if you could also add (existing) members based on username or full name - ideally also with auto-completion. (I appreciate that auto-complete of email addresses may raise privacy/security concerns).

I'd be happy to assist with adding this functionality (I speak python and some angular, but am unfamiliar with the project architecture so am not sure what would need to go where).

Looking at the code, it appears that there is already a method getUserByUserName which would get most of the required functionality (at least for for the simple case of full usernames).
(https://github.com/taigaio/taiga-front/blob/2319ba1766f2c5e6273ac7db395eac5c1ff3dde7/app/modules/services/user.service.coffee)

Any thoughts on this as a feature?

[superalex]

Hello @mrichar1,

A think this one could be a very interesting one, thank you very much for your interest in contributing to Taiga. Right now the service call you commented call the API endpoint /api/v1/users/by_username=XXX which matches exactly the username so if developing this feature I think the the users API should allow filtering by partial username/fullnames too (using the email will raise privacy/security concerns as you said).

This feature looks like a major change in Taiga, we have defined a small workflow for this changes so we can better coordinate our efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project.

1.- User Experience: The functionality will require some wireframes or ideas to be developed correctly. A good UX its an essential part of Taiga success.
2.- Design: The design should respect the Taiga style. Try to reproduce other areas of the site. The taiga design team will review this proposal as well.
3.- Development: The last step is the development. Remember to add unit and integration test in taiga-back code and unit and e2e test for taiga-front part. We have the API well documented too in https://taigaio.github.io/taiga-doc/dist/api.html
4.- Pull request: Remember to add a good description and screenshots are welcome too. Once the pull request is done, someone else from the team will review the code to ensure that if fits in the good practices and styles. If it does, the PR will be merged and will be on the next Taiga release.

If you think you are not able to do one or more of the parts of the process, your contribution is still welcome, but we cannot ensure that it will make it soon into the Taiga core anytime soon. It will depend on our priority backlog.

Regards!,

[mrichar1]

I'd be interested in taking on some of this - at least starting with the API side of things (my python is stronger, and my UX/UI skills weaker).

Looking at the backend code, it appears that I'd need to do the following:

• base/api/utils.py:
  
  
  
  • add a get_list_or_404() to accompany get_object_or_404()
  
  
• users/api.py:
  
  
  
  • starting with by_username() as a 'template':
  
  
  • add by_full_name() - same as above, but uses full_name, not username
  
  
  • add by_XXX_part() (or by_XXX_contains() or some other suitably named methods) - same as above, but uses get_list_or_404() and accepts some kind of wildcard matching (using one of Django's Field Lookups like contains or icontains).
  
  

Does that sounds like the right kind of direction to make a start in?

[superalex]

Hello @mrichar1

I don't think a get_list_or_404 is needed, if there are no results an empty list should be enough.

Taiga code is based on django-rest-framework you could check it's doc to see how adding filters can be achieved.

Without a first UX/design validated approach the risk is that all these changes never hit the Taiga core :(

[mrichar1]

OK - starting at the other end then - the inspiration for this feature is from gitlab, which has a very similar interface to add members to projects: http://doc.gitlab.com/ce/workflow/add-user/add-user.html

I envisage the taiga add member form looking something like:

The input field is now an auto-complete field. If a match is found/selected, this is used to add member by username or full name. If no match is found, then the string is assumed to be a full email address, as happens currently.

Does this make a suitable start at steps 1 and 2? I appreciate UX/design review is an important part of Taiga, and am happy for this to be fleshed out before any code comes into being...

[Xaviju]

Hi @mrichar1
If the search box shows a autocomplete box, would you please show how would it look? I would be happy to make suggestions or help you with the design of the module.
Do we already have some information of the user (as its picture, name or role?) to make the autocomplete process easier?

Great feature!

[bameda]

For example, to be less intrusive: username, fullname and photo.... (we don't know the role because she or he is not a member of the project).

[mrichar1]

The gitlab docs linked above show their auto complete in progress for a user - this shows photos, full names and usernames in a drop down. 'something like this' perhaps? (with appropriate app to return these fields of course).

I don't know if you have an angular 'toolkit' already in use which would offer auto-complete functionality? I'm aware there are lots of them available, but don't have any preference/recommendations to make.

[superalex]

I'm thinking about a scenario where I could use this feature in an evil way, as Taiga doesn't require users to accept being members of a project. If I just want to spam all the Taiga users I could do the following:

• Invite all the taiga users to a project (with a script trying all the sets of initials)
• Create an issue
• Add all those users as issue watchers (another easy script)
• Update the issue description with SPAM text

This could generate an email notification to all the Taiga users (email notification level is "only involved")

Right now as you must know the user email and that data isn't exposed anywhere in the API we are safe.

A solution could be that the new endpoint to list users only allows you to autocomplete from your "contact" list (https://tree.taiga.io/profile - contacts tab). Those users (from the API /api/v1/users/USER_ID/contacts) are people who you are working with in another projects so this kind of attack shouldn't be possible.

[bameda]

The autocomplete only works with your contacts

[superalex]

@bameda I think it should work that way but as it's still not developed at all I was thinking about how it should work. In that case that endpoint could add new filter params and be used from this box.

[mrichar1]

I'm wondering about this now too.

I can see 2 possible ways to limit this kind of attack:

1. Treat all adds as invites, notify the user and get them to confirm/reject. Notification by email, and/or in-app.
2. Rate limiting adding members to a group.

I think 1 is the best option, as rate limits just slow down, rather than stopping such attacks.

Limiting auto-complete to existing contacts still adds the initial step of knowing someone's email address, which would be nice to avoid completely in some cases. For example, you might want to invite someone from another project onto yours, without having any info about them other than what their profile page shows. And some people just don't like sharing email addresses.

As an aside, in the current system can you spam the world by email inviting a bunch of addresses with a custom (spam) message (I.e not even addresses associated with taiga)? Is the custom message sanitised for links etc?

[superalex]

I think another option could be autocompleting just with your contacts but not only by email, that autocomplete from your contacts could work with username, fullname or email, that way if you are working with someone in another project you can easily invite without knowing the email.

[mrichar1]

I still think that requiring someone to be a contact first is potentially limiting. Take this issue for example.

Say you have this in taiga as a user story, and decide the best thing to do is to assign some tasks in it to me. Now you need my email address, but that's not 'public information', unlike my name and username, which are visible on my taiga profile.

If there was auto-complete, all you have to do is search for me by full name/username (which is easier to find/share) and confirm the profile you find is me.

The important bit of course is that any requests must still come as invites, not automatic adds, to prevent spam.

[superalex]

In that situation I would prefer that you requested to be a member of the project, so I as a project admin could accept your request and assign you that US.

[karolherbst]

Would it be possible to add such a feature without autocompletion? Adding somebody by full username or name would be already a big help. Remembering email addresses is much harder than names.

[superalex]

Hello @karolherbst right now taiga allows autocompletion by username or full name so you don't need remembering email addresses

[karolherbst]

@superalex okay, sadly it doesn't work for me, but maybe this is also caused by the fact, that all our users are registered via gitlab/github logins

[superalex]

@karolherbst it should work too in that case but those users should be considered as contacts, do you share any other project with them?

[karolherbst]

@superalex no, I do not share any project with them.

[superalex]

So that's the problem @karolherbst the autocomplete/suggestion feature only works for "contacts"

[karolherbst]

@superalex yeah okay, but that doesn't bother me at all. What bothers me, that I can't even put in the full username to add somebody to the project. And in my use case, getting the username of somebody is far easier than getting the email address.