Redmine

My vote goes for this feature. Got used to that in Confluence...

It would be very useful, I agree.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Just wanted to let you know, that it has been implemented in WikiNG...

+1

+1, but please check this link http://www.redmine.org/issues/13919

+1

My +1 here. The most nice would be to use twitter-like annotation: Felix Schäfer

+1 for Twitter-like user-mention (see also #13919)

Also, this feature raises the issue about notification when a user is mentioned in an issue/wiki page/commit msg...

+1
This would be very useful for me too. It would be nice if I could create the RACI Matrix and reference eache person by their own users page.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Marius BALTEANU, thank you for the patch. I really want this feature.

But I am not certain about whether the proposed implementation is proper or not because User#login is treated as secret information in the current implementation of Redmine. Please see source:trunk/app/views/users/show.html.erb@16464#L9. Only admin can see User#login.

1. First Name and Last Name cannot be used, it is hard to find a user after these properties and also, they are not unique.
2. ID could be a solution, but without an autocomplete feature to search users like in the watchers modals it'll be hard to find their ids. Also, I find it quite strange to see "user:107353" in texts comments/wikis.
3. Email addresses, but the users have the option to hide this attribute.

From my point of view, User#login is the best solution and I do not see to many disadvantages because:
- in many companies, you can easily guess the login name of your colleagues because they have the same format
- comparing with the Last Name, First Name or the email addresses, it is less considered personal data.
Of course, if you get the login name of another user, you can try some brute force to login with his user, but this "security" issue can be prevented using a mechanism like Captcha.

@Go Maeda, how do you see this implementation? I'm open to create a patch only with "user:id", but I want some feedback before. In this note (#6690#note-2), Jean-Philippe Lang said only about the user.visible? check that wasn't implemented in the respective patch.

Go MAEDA wrote:

I prefer using User#login as you suggested but it violates current design.
I think we should change current design of Redmine. That is, Stop handling user#login as secret information. Personally I don't think User#login as confidential. Many services treats user id as public.

Totally agree. I'm going to update the patch this weekend and after that, we'll see what Jean-Philippe Lang says about this change.

I think it's fine to not hide login names. I would think that users don't expect logins to be secret/personal today. And I also like the feature ;-)

Marius BALTEANU wrote:

Thanks Go MAEDA and Jan for your feedback. I've attached a new patch that shows the login attribute in user page also for non admin users.

Thanks for working on this. I found that we also have to change the behavior of API.

diff --git a/app/views/users/show.api.rsb b/app/views/users/show.api.rsb
index e4c49f9b8..e711bc482 100644
--- a/app/views/users/show.api.rsb
+++ b/app/views/users/show.api.rsb
@@ -1,6 +1,6 @@
 api.user do
   api.id         @user.id
-  api.login      @user.login if User.current.admin? || (User.current == @user)
+  api.login      @user.login
   api.firstname  @user.firstname
   api.lastname   @user.lastname
   api.mail       @user.mail if User.current.admin? || !@user.pref.hide_mail

Marius BALTEANU wrote:

Regarding the proposed syntax with id (user:107353), even if it's easy to be added, I think that it is not worth it because is hard to retain the ids. For example, I don't know my user id from the instance that I administrate for more than 3 years.

1. many people (including myself) do rely on the usage of user ids (they are easily retrievable — also for non-admins — by looking at the target of the linked [to users profile] username)
2. it would make it more consistent with the existing Redmine links which all accept an id variant

¹ I do however see the issue that with opening up the users' login, we make it easier for bad adversaries to bruteforce user account passwords. This might be considered a blocker for some users...

Thanks for you feedback.

Mischa The Evil wrote:

I agree that an implementation based on User#login is ok¹, but I also like to second the above quote, for two reasons:

1. many people (including myself) do rely on the usage of user ids (they are easily retrievable — also for non-admins — by looking at the target of the linked [to users profile] username)
2. it would make it more consistent with the existing Redmine links which all accept an id variant

We can do it, I'll add a new patch soon to add the functionality also for ids.

¹ I do however see the issue that with opening up the users' login, we make it easier for bad adversaries to bruteforce user account passwords. This might be considered a blocker for some users...

Agree with you, but the solution for this problem is not to hide the login names (which are easily to guess in many companies), but to use a mechanism like Captcha (see my note #4179#note-43) which could be very useful on this site too.

In my company we have firstname.lastname as a default for user logins. Nevertheless, we have a wiki page that lists all logins so we can mention them if anyone forgets anything.
As you can see, we don't think displaying user logins is such a problem. I understand it could be a security issue, but I'm not worried about that. We encourage people to change passwords every now and then.

Jean-Philippe Lang wrote:

The patch that adds support for links to user is committed, thanks.

But I prefer to postpone the display of user logins on profiles until we get more feedback. Those who are fine with this can still use logins as display names right now.

Jean-Philippe Lang wrote:

The patch that adds support for links to user is committed, thanks.

I'm glad to see this integrated. However, the current implementation is practically useless to all sites that use a user format (display name) other than the one consisting of the user login, as (regular) users won't be able to retrieve the user logins under such circumstances. This can be prevented by also adding support for a numerical variant of the link (ingo denner or more preferable user#id) like eg. provided by Marius' additional patch attached in note-56. Would you please consider that for inclusion into 3.4.0?

Jean-Philippe Lang wrote:

But I prefer to postpone the display of user logins on profiles until we get more feedback. [...]

I have opened #26127 to track that specific proposal.

Marius BALTEANU wrote:

Mischa The Evil The Evil, I've attached the patch that adds support also for ingo denner (user:1).

Thanks. I've had a look at it and it seems okay. One note though: all link keywords that take a numerical id are using # as the separator whereas the ones that take a name, instead use the : separator. With your patch (as also proposed by the OP of this issue) we diverge from this convention. Maybe it's better to use user#id along with user:login and @login. What do you think?

Mischa The Evil wrote:

Thanks. I've had a look at it and it seems okay. One note though: all link keywords that take a numerical id are using # as the separator whereas the ones that take a name, instead use the : separator. With your patch (as also proposed by the OP of this issue) we diverge from this convention. Maybe it's better to use user#id along with user:login and @login. What do you think?

I agree with you, I'll update the patch to use the # as separator.

Marius BALTEANU wrote:

Here it is.

Nice. LGTM! Thanks for working on this.

@Jean-Philippe: I think that this issue would be completely implemented for 3.4.0 when note-65 (instead of note-56) patch gets integrated along with r16636 and r16638. Please consider the integration of this last patch.

Seem it isn't working well with syntax "user:abc@example.com" (Login name contain "@" character)

Vu Anh wrote:

Seem it isn't working well with syntax "user:abc@example.com" (Login name contain "@" character)

This issue has been closed and the feature has already been delivered. Could you open a new issue to report the problem?

Go MAEDA wrote:

Vu Anh wrote:

Seem it isn't working well with syntax "user:abc@example.com" (Login name contain "@" character)

This issue has been closed and the feature has already been delivered. Could you open a new issue to report the problem?

Done. #26443.

@Vu Anh: you can alternatively use the short syntax (@abc@example.com), which should work fine.