| Summary: | PersonProposalProvider should display real name when available | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | David Shepherd <david.shepherd> | ||||||||||||
| Component: | Mylyn | Assignee: | David Shepherd <david.shepherd> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||
| Severity: | enhancement | ||||||||||||||
| Priority: | P3 | CC: | david.shepherd, steffen.pingel | ||||||||||||
| Version: | unspecified | Keywords: | contributed | ||||||||||||
| Target Milestone: | 3.5 | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Windows 7 | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
David Shepherd
Not sure that the real names are actually available, noticed that TaskAttribute.USER_ASSIGNED_NAME is depreciated. Makes sense. As a first step you could extend PersonProposalProvider to work with IRepositoryPerson objects. Created attachment 174200 [details]
Patch to enable PersonProposalProvider reuse
This patch should allow clients to reuse the PersonProposalProvider by subclassing it and implementing the createPersonProposal method and/or the getPrettyName method. This would allow clients that have access to display names (i.e., pretty names) to show those names in the content assist while still providing the normal values as content for inserting into the field.
Also in this patch: updates to how the address set is being populated, including adding users that commented and added attachments.
Please provide feedback on what needs to be updated on this patch. Thanks!
Created attachment 174201 [details]
mylyn/context/zip
Looks good. Two thoughts: * I don't think it's worth introducing the factory at this point since clients need to subclass anyways. Can you merge the factory into PersonProposalProvider? * All creation of repository person objects should go through the addPerson() method. You probably want to pass in the TaskAttribute. Look at TaskAttachmentMapper to get the right one for attachment authors. David, are you planning on addressing the points in comment #5? Created attachment 176947 [details] Updated Patch (In reply to comment #5) > * I don't think it's worth introducing the factory at this point since clients > need to subclass anyways. Can you merge the factory into PersonProposalProvider? Merged into PersonProposalProvider. > * All creation of repository person objects should go through the addPerson() > method. You probably want to pass in the TaskAttribute. Look at > TaskAttachmentMapper to get the right one for attachment authors. All creation of repository person objects moved to addPerson. I'm not sure I understood this comment exactly right so please check out the patch. It seems like the addAddresses() method is not actually transferring data from personsOfInterest to addressSet. Can you take a look? Created attachment 176951 [details]
updated patch
Updated patch to transfer data. The check for user_cc is a bit odd, please review.
Thanks. I have applied the patch with a few modifications. Created attachment 176953 [details]
mylyn/context/zip
|