Ticket #9305 (closed PLIP: fixed)

Opened 7 years ago

Last modified 6 years ago

Use real names instead of usernames

Reported by: laurenskling Owned by: ralphjacobs
Priority: minor Milestone: 4.0
Component: Unknown Version:
Keywords: Cc: plip-advisories@…, grahamperrin@…

Description (last modified by wichert) (diff)

Plone is mostly used in friendly environments where people know each other by name, like on Intranets. Showing usernames doesn't give much information, as it still doesn't say much about the identity of a person. I see no objections in showing real names by default, throughout Plone (On search results, comments, versioning, etc.)

Proposal:

  • Use realnames instead of usernames by default in naming users.
  • Make this configurable in the Plone Control Center, if users need to be anonymous.

Risks:

Unmeant revealing of real names when upgrading to Plone 4.

Attachments

Fullname proposal.pdf Download (184.3 KB) - added by esteele 7 years ago.
Implementation proposal
performance_report.txt Download (7.4 KB) - added by ralphjacobs 7 years ago.
performance report (based on search queries)

Change History

comment:1 Changed 7 years ago by alecm

This is a very good idea. There will be a performance impact, so we'll need to think about caching this lookup. If users want anonymity, I expect they would choose anonymous "full names". I don't believe there's a real need to make this configurable.

comment:2 Changed 7 years ago by elvix

+1. We should have had this ages ago (We have implemented it in at least one intranet already). It is much more helpful to users.

There may be a small performance impact. We might want to look into caching or a special username btree storage.

There is no need to have this configurable per user, but it must be configurable per site whether to display author information to anonymous users(i actually think this is configurable already in Plone)

comment:3 follow-up: ↓ 16 Changed 7 years ago by laurenskling

I meant switching per site, it wasn't very clear in my text. If one makes a public Plone site and does not want real names to be shown, it should be possible somewhere to switch it. If that's possible in ZMI or something, it's fine with me.

comment:4 Changed 7 years ago by pupq

+1 from integrators. People ask sometimes.

I wouldn't worry to much about caching this--I don't think most people would expect "the moment I change my username, it will change everywhere". I think it would be reasonable for that to be aggressively cached.

comment:5 Changed 7 years ago by erikrose

Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)

comment:6 Changed 7 years ago by smcmahon

  • Cc plip-advisories@… added

comment:7 Changed 7 years ago by MatthewWilkes

FWT Vote: +1

comment:8 Changed 7 years ago by rossp

FWT Vote: +1, provided there's an implementor.

comment:9 Changed 7 years ago by davisagli

FWT vote: +1.

comment:10 Changed 7 years ago by raphael

FWT vote: +1.

comment:11 Changed 7 years ago by calvinhp

FWT Vote: +1

comment:12 Changed 7 years ago by esteele

Approved by FWT vote.

comment:13 Changed 7 years ago by esteele

  • Owner set to laurenskling

comment:14 Changed 7 years ago by jaroel

  • Status changed from new to assigned
  • Owner changed from laurenskling to jaroel

comment:15 Changed 7 years ago by jaroel

  • Owner changed from jaroel to laurenskling
  • Status changed from assigned to new

comment:16 in reply to: ↑ 3 Changed 7 years ago by rossp

Replying to laurenskling:

Emailed laurens, he said he didn't have an account on Trac. I asked him to get an account here so we can record history and discussions here. Oddly, I see that Laurens *did* actually comment on this ticket in the past, in the comment this is in reply to. So is seems he does have an account.

I see in the last two comments, that jaroel tried to accept the ticket on Laurens' behalf. We think it's important that implementers are responsive in Trac and the FWT is very eager to see this PLIP included in Plone 4. :) So Laurens, please straighten out your Trac access and accept the PLIP.

Thanks!

Changed 7 years ago by esteele

Implementation proposal

comment:17 Changed 7 years ago by grahamperrin

  • Cc grahamperrin@… added

comment:18 Changed 7 years ago by laurenskling

Can't I just say that I accept in a comment? Don't think my account is really just a TRAC account. I'm just using my plone.org username.

comment:19 Changed 7 years ago by wichert

  • Description modified (diff)

I also posted this to the framework-team list, but for archiving purposes I'll add my comments here as well.

I'm afraid I do not agree with the proposed implementation. Adding a new method to the membership tool is not useful since there already is a getMemberInfo() method which returns almost the same information. There are no performance differences between getMemberInfo() and a separate getFullName() method.

I also don't buy the lookup mechanism mentioned in the PDF: you are essentially creating a persistent cache system, which means that suddenly page views can trigger ZODB writes, which is very bad for high performance sites. It also will miss all user changes created directly in external user sources such as LDAP, AD and SQL databases, leading to incorrect and possibly confusing behaviour.

If there is a performance problem, which has not been proven yet, it should imho be solved at a different point. All the required PAS methods are already ZCacheable, so that is not expensive. The single object wakeup to get the users member data is also not that bad, and I would be very surprised if that shows up in a real world profile.

Changed 7 years ago by ralphjacobs

performance report (based on search queries)

comment:20 Changed 7 years ago by ralphjacobs

I've made an implementation in the 9305 branch ( https://svn.plone.org/svn/plone/Plone/branches/plip9305-fullname/) which changes a few templates to show the fullname instead of the 'creator'. The fullname comes from getMemberInfo, from the portal_membershiptool. I've executed a few benchmark tests which can be found in performance_report.txt (see above, as attachment). My first impression is that it's a bit slower, but acceptable. Note: it's not configable in the Plone Control Center.

comment:22 Changed 7 years ago by ralphjacobs

  • Owner changed from laurenskling to ralphjacobs
  • Status changed from new to assigned

comment:23 Changed 7 years ago by ralphjacobs

This PLIP is ready for review.

comment:24 Changed 7 years ago by esteele

Your PLIP has passed the Framework team's initial review. Feel free to discuss any suggested changes either here in the PLIP ticket or on the mailing lists. Final deadline for this PLIP is set for September 30.

comment:25 Changed 7 years ago by ralphjacobs

Ready for merge, checked the review by rossp. Only template changes implemented.

comment:26 Changed 7 years ago by davisagli

FWIW, most of the test failures that Ross noted look to me to be due to the fact that the Plone branch for this PLIP was created prior to some refactoring in CMFCore which required me to make an accompanying change in Plone...so probably aren't worth worrying about. Of course, we expect you'll make sure that merging this will not introduce new test failures on the main Plone 4 branch.

comment:27 Changed 6 years ago by rossp

Just reviewed my review. I was a strong +1 for merging when I reviewed it the first time, so I'm +1 for merging now.

comment:28 Changed 6 years ago by esteele

This PLIP has been accepted for merging into Plone 4.0

The final vote was: Alec Mitchell +1 David Glick +1 Erik Rose +1 Laurence Rowe +1 Matthew Wilkes - Ross Patterson +1

Please merge your branches into the Plone 4.0 head by end-of-day Friday Oct 16. If you need assistance with merging, please contact me.

We'll be assigning a documentation ticket to this PLIP shortly. Please assist the docs team in documenting the changes and new features that this PLIP introduces.

comment:29 Changed 6 years ago by esteele

Please assist the doc team in creating/updating documentation relating to this PLIP. See #9612.

comment:30 Changed 6 years ago by robgietema

  • Status changed from assigned to closed
  • Resolution set to fixed

This plip has been merged.

Note: See TracTickets for help on using tickets.