If real names behaviour could be reverted (in config) to old-style handling and it conflicted with @mention or something, you could cut off automatically the whole @mention functionality and all the stuff that conflicts with it. Not everyone uses @mention. Supposedly.

Also some users (for example outsourced contractors) historically have usernames as their emails. So showing usernames all the time is inappropriate for our tasks. It would be quite reasonable for us to display real names by default while usernames as tooltips if it has to be so (or better not at all).

For the projects that have no strict requirements for usernames this change ruins the ui and exposes what shouldn't be exposed.

There could be javascript solutions for @mentions using real names. For example suggestions may pop up triggered by @ sign. I understand that it supposedly entails big code changes and editor area rework. That's all for now. :)

We use realnames for not exposing usernames to public.

I am not aware this was ever possible.
You can click on the real name in activities to see the username on view_user_page.php.

Real name speaks for itself than a username. With $g_show_realname we make usernames not that obvious as they are no that informative and inconvenient for comprehension.

It is common practice to always show usernames. For example:

• Github uses usernames
• PHPBB uses usernames
• Twitter shows usernames + real name next to tweets

Hiding usernames was not ever a goal and was always discoverable.

ok. When you know the rules, you follow them. We know that some web-stuff requires usernames. But here the rules has changed. And that changed the way the info is displayed in comparison to how it used to be. By making private I'm not speaking about hiding data rather than I'm speaking about exposing relevant data like real names. E-mails (some of our users has it as usernames) are irrelevant in this case while real names from profiles are relevant. For example, emails like usernames not only look ugly, they don't even work for comprehension and personalisation.

Proposal from 0024087:0059267

What about replacing $g_show_realname by something like $g_display_user_format ?

#define ( 'USERNAME', 0 );
#define ( 'REALNAME', 1 );
#define ( 'USERNAME_REALNAME', 2 );
#define ( 'REALNAME_USERNAME', 3 );

$g_display_user_format = USERNAME;

• USERNAME display user name, no real name
• REALNAME display real name, display user name if real name is not set or access is not allowed
• USERNAME_REALNAME display user name, real name as bubble or in brackets, if access is allowed
• REALNAME_USERNAME display real name if set and access is allowed, display user name as bubble or in brackets. If not set or not allowed, display user name.

"stainlessstill" +1

I have the same problem

0024139:0059327

If this format is displayed on the form instead of USERNAME, then I agree it. This will be solution the problem

0024139:0059327

What about replacing $g_show_realname by something like $g_display_user_format ?

If I get that right, that will solve the problem. If old mantisbt installations had an option to manage new username display rule, that would be a great lifesaver.
Thanks for not ditching it and for your supportive attitude. :)

Edit [dregad]: markdown

"stainlessstill" +1

I have the same problem

We work with physical person and not virtual user.
Showing usernames like "CA1245" or "ME9645" all the time is inappropriate for our tasks.

Then i modifed function prepare_user_name in prepare_api.php with using show_realname : cf JPG

but, If it's possible to add an option to manage how we can show username that will be great.

thanks

prepare_user_name.JPG (105,842 bytes)   

prepare_user_name.JPG (105,842 bytes)   

I just reverted back from 2.14.0 to our previously installed version 2.10.0, because we need the old behaviour which instantly shows the real names in all places and doesn't need an extra mouse-over to see it. Therefore:

+1 for atrol's proposal, or for any other option which makes it possible to see real names in all places.

Dear
vboctor, atrol,

jensberke +1
We reverted back to 2.11.1, because we use Real for not exposing usernames to public since the beginning < 0.19.x
Showing usernames like "J01245x" is inappropriate for our use case

We are waiting for getting this old function back

Thank you!

Dear mantisbt Team,

I'm sorry to say this, but this is a showstopper or Blocker, please realize 0024139:0059327 immediately !

Best regards,

Karl

$g_show_realname is a important functionality for me (and others).
I'm blocked in 2.11.1 version
if is a configurable option, I don't understand why was deleted it
Best regards

Does this need a blocker ticket for 2.15, really?

We reverted back to 2.11.1, because we use Real for not exposing usernames to public

@mahindra even if you go back, usernames are exposed to public, see my note 0024139:0059243

You can click on the real name in activities to see the username on view_user_page.php.

Thank you for a the answer atrol.
It's ok to See the usernames after clicked on the real name in our policy, because they are not obviously in the ticket.
It would be great to make them visable to Admins or Manager by Projekt richte - but we are not in paradise.
It's exzellent to have no IDs in Statusmails

Add a User to a Ticket should be made in an alternativ-way in sent reminder - when it's checken - the user will track the ticket only, without an reminder notice

In a closed mantis with private and child projects world

Wartepools and Leichen im Keller Pools für Verbesserungen - wie überall Status des and so on

2.11.1 was near perfekt in this Realname=ON sight

Great, if Managers could allow Reporters private notices to play an open project game

I mean reporters can see private notices only in their projects in 2.11.1 since the begin

If you parameter it as describet in config defaults

Thats all - ok the date settings and basics

Rest is managed in mantis via project and possibilities
Exzellent the selektive mails last year - not so much

+1

Relateted to 0024435 , which will not be necessary

I try to summarize or rephrase what the problem is, what uses cases have to be considered, and why some people, like me, think this has to be of high priority and fixed soon. This ticket actually isn't only about privacy of usernames (as the summary suggests). There are two things two consider:

• Privacy: some, but certainly not all Mantis installations require the username or the real name to be private, for whatever reasons. With privacy and data protection becoming a more important topic in general these days, this is a valid point to consider.
• Usability: the statement by @vboctor above (0024139:0059253) which says that it's common practice to use usernames at Github, Twitter and so on leaves out a (certainly not small) part of other communities and projects which are working completely different: they know each other by their real names and want to immediately see who the reporter of a ticket is or who wrote a note. Seeing real names immediately makes it a lot easier to talk about the tickets and assign them, instead of having to remember or figure out each time if "jdoe1" is Jane Doe and "jdoe2" is John Doe or if it's the other way around. Or even worse: trying to figure out if user "user123" or "user456" is John Doe. Another use case: If Mantis is used for a support desk, seeing real names may also be important in order to be able to address the user of a support request correctly by his or her real name. Therefore I'd say it's also common practice to use real names. It depends! :)

The requirements of a project which uses a Mantis installation determine if either only one or even both of these aspects have to be considered: if either only the username, only the real name or both must be displayed.

As a result, I suggest to raise the priority of this ticket, target the fix for one of the next versions and change the summary into something like this:

"Make display of real name and/or username configurable"

As already said, the solution proposed by @atrol above (0024139:0059327) seems to address all this.

@jensberke thanks for the excellent summary. I agree with you and support the proposed approach.

some, but certainly not all Mantis installations require the username or the real name to be private

Requiring the username to be private is a new feature request, as this was not possible in any earlier Mantis version.
We would have to introduce a new option similar to $g_show_user_realname_threshold, something like $g_show_user_username_threshold

As already said, the solution proposed by @atrol above (0024139:0059327) seems to address all this.

Unfortunately not, see above

Furthermore we have to consider that users are not forced to enter their real name.
What to do if $g_show_user_username_threshold = NOBODY and real name is not set?

And there is 0024239 to consider, where we use always username in e-mail notifications starting from 2.13.2.
To fix it, there is some redesign needed, see my comment https://github.com/mantisbt/mantisbt/pull/1330

Don't send realnames if $g_show_realname = ON;
This is a quick workaround as a clean solution needs some redesign.
At the moment $g_show_user_realname_threshold is considered based on the current user.
This is wrong, as the option must be considered based on the recipient of the notification.

Until there is a complete idea what to do and someone willing to implement it, maybe my PR to fix 0024436 is an acceptable compromise at least for some users.

0024139:0059829 Thank you jensberke
In our closed Mantis the Admin registrates Users with their Realnames

Requiring the username to be private is a new feature request, as this was not possible in any earlier Mantis version

I know. My summary was rather looking forward than backward. I should have written that Mantis installations may require the username or the real name to be private in the future.

Until there is a complete idea what to and someone willing to implement it, maybe my PR to fix 0024436 is an acceptable compromise at least for some users.

Yes, for my requirements, fix 0024436 will suffice.

Scenario:

If a person who wants you something bad comes into the possession of your User-ID (real name = OFF or Mantis >2.11.1), all this Person will have to do is to guess the password in order to take over your identity.
The user ID is 50% of the login, mails and screenshots of tickets are sent externally - etc.
(What you or the admin write in the field real name is another topic.)

$ g_allow_signup = OFF - is therefore mandatory for many Mantis.

0024139:0059830 thank you degrad.

until we get this theme organized, we have to live on 2.11.1 with the following gap 0024186: [security] CVE-2018-1000162: XSS vulnerability in Parsedown library
That's why I reported 0024432

<<<The real solution to add users to a ticket is a drop down list like 0012557 >>>
If Realname is on - it shows realnames like Mantis before 2.12 in every User field
If Realname is off - it Shows the User ID

Similar to the filter selection for user
Simple and clean
Please go in this direction and delete 0023375 go back to the previous solution in visualization Realnames up to version 2.11.1 this was clean and improve adding a user to a ticket with a drop-down list

You are moving in circle with 0024436, 0024435 and all the other IDs currently

In order to see this topic you have to work in the corresponding representation - only user ID or only real name instead of user ID - then it is easy to understand

Please have a look at PR (not tested, just coded until now) https://github.com/mantisbt/mantisbt/pull/1351
I hope this is a good compromise for all.

@vboctor as you introduced the current behavior. What's your opinion on that?

Thanks for the support atrol
For an old man
If realnames = on - this means Relnames will be displayed
and a mouseover shows the user ID?
If $ g_show_assigned_names = ON; do I also see the real name there?
Also in view_all_bug_page.php and also in the filters and mails?

If so

That would be a good compromise right now in a closed company Mantis (eg service desk)

($ g_show_user_realname_threshold is only useful if realnames, = off

• this is the usecase in an open Mantis like mantisbt.org for Managers, admins, developers to see this Information and hide it to Reporters and Testers and the WWW
  For realnames = on $ g_show_user_realname_threshold should have no effect - it is not needed here)

If realnames = on - this means Relnames will be displayed and a mouseover shows the user ID?
If $ g_show_assigned_names = ON; do I also see the real name there?
Also in view_all_bug_page.php and also in the filters and mails?

yes to all, but it would be good if someone supports testing my PR.

You can download the code from https://github.com/atrol/mantisbt/archive/username-realname-proposal.zip
As Github does not add 3rd party packages to the zip, after download and unzip, you have to add a copy of the folder vendor from a 2.14.0 installation.

Many thanks atrol!

I looked at the trial version - the only thing is with the selection boxes, where the ID is still directly visible.

It would be nice to hide the ID there.

Everything else looks beautiful - including mails.

Test was carried out with

'#' - show users with their real name or not
$ g_show_realname = ON;
$ g_show_user_realname_threshold = ANYBODY; # Set to access level (eg VIEWER, REPORTER, DEVELOPER, MANAGER, etc)
'#' $ g_show_assigned_names = ON;

NICE TO HAVE PARAMETERS FOR - in the future - but I will take this compromise before, please
$g_show_username = OFF
$g_show_user_username_threshold = MANAGER;

When do we have that in 2.15 ??? - really cool!!!!!

mails_ok_Realname.png (10,952 bytes)   

mails_ok_Realname.png (10,952 bytes)   

view_all_bug_page.php-korrekt.png (25,912 bytes)   

view_all_bug_page.php-korrekt.png (25,912 bytes)   

korrekt_view.php.png (20,666 bytes)   

korrekt_view.php.png (20,666 bytes)   

filter shows id nice to have this will be not so.png (27,766 bytes)   

filter shows id nice to have this will be not so.png (27,766 bytes)   

I looked at the trial version - the only thing is with the selection boxes, where the ID is still directly visible.
It would be nice to hide the ID there.

This is the compromise.
Keep the IDs at this place to support easier @ mentions.

When do we have that in 2.15 ???

Until now there is not any feedback from any other Mantis team member.
If they agree on the approach, it's there in next nightly build and should be there in official 2.15.0 in early June.

Thank you I think the compromise is OK for all.
It would be great to see this in 2.15.0 so we can do the upgrade.

Maybe you will have a look to a listbox to add users in future release.

@atrol: I just tested https://github.com/mantisbt/mantisbt/pull/1351 too. It works and is OK for my requirements. Thanks a lot for providing this compromise.

Thanks @mahindra and @jensberke for testing.

I documented the expected behavior to discuss https://github.com/mantisbt/mantisbt/pull/1351#issuecomment-391495880

Expected behavior after merging the PR

Thanks again for the support and reasoning in https://github.com/mantisbt/mantisbt/pull/1351

The documentation fits the test results and is also an improvement for realname = off according to the documentation.

Please be assured that both representational views (real name OFF and / or real name ON) have their justification - above based on the documentation of the compromise this is clearly shown.

We wait for 2.15 and are still sticking to 2.11.1. until the representation of Realname ON is fixed.

@vboctor
https://github.com/mantisbt/mantisbt/pull/1351#issuecomment-391495880 below
realname = on overrules show_realname_threshold which is useful for realname = off.

If realname is enabled, then the realname should be used as elsewhere in email notifications, csv export, and excel export.

Thanks for this advice

@atrol
you said in https://github.com/mantisbt/mantisbt/pull/1351#issuecomment-392003699
" All I could offer to replace this PR, is a new PR that reverts even more to the old behavior but keeps just your refactoring to have less places where we deal with user/real names."

Sorry - but we do need 0024139:0059929 nothing else covers the requirements!

it would be good, a few others would deal with a Relname Mantis once - and what advantages that offers in a version <= 2.11.1.

Resolved in 2.15.0 after merge of https://github.com/mantisbt/mantisbt/pull/1351

This is a theme from the versatility of Mantis that makes it so good, on the other hand, to understand quite abstractly - especially if you do not need some function yourself.

From an application point of view, I can only recommend user selection - where possible outside of the text (reminder, combo, etc.) to make and ask for display conversions - straight, when it comes to naming - straight to lead.

Thank you very much again to atrol and the mantisbt-team!

I will report if I get topics because of the better user-ID view, which is better hidden in ours, where possible.