Ticket #460 (closed defect: fixed)
Opened 8 years ago
Last modified 6 years ago
Use 'user settings' for reporter/editor in Tickets and Wiki
| Reported by: | daniel | Owned by: | daniel |
|---|---|---|---|
| Priority: | normal | Milestone: | 0.8 |
| Component: | general | Version: | |
| Severity: | minor | Keywords: | session |
| Cc: | |||
| Release Notes: | |||
| API Changes: | |||
Description
Trac should automatically use name and email from user settings/prefs to fill out contact information for tickets, wiki edits and comments.
Attachments
Change History
comment:1 Changed 8 years ago by daniel
- Status changed from new to assigned
comment:2 Changed 8 years ago by daniel
- Resolution set to fixed
- Status changed from assigned to closed
comment:3 Changed 8 years ago by cap
- Resolution fixed deleted
- Status changed from closed to reopened
util.get_reporter_id() simply returns the authname if a user is authenticated. I can't see any code to match up authnames with email addresses elsewhere, so it seems that authenticated users can't get email notification. A fix for #464 would fix this, but it seems like a better solution to both tickets would use the email session var regardless of authentication status.
comment:4 Changed 8 years ago by daniel
comment:5 Changed 8 years ago by cap
I was a unsure about reopening this, but [617] doesn't change my original complaint. Let me describe the behavior I was objecting to:
Without being authenticated, I click on the settings link and enter my full name and email address (Cap Petschulat <cap@…>). I create a new ticket and the reporter field is filled in automatically with name and email (I think via the call to get_reporter_id). This is as expected.
Now I authenticate myself (username cap) via the login link. I click on settings and fill in a name and email address. When I create a new ticket, the reporter field is populated with my authname alone—no email address.
If session variables really should be ignored in this case, the option to set them should probably be disabled once the user is authenticated. My statement that authenticated users can't receive email notification was overly dramatic, but I still think something is off here.
comment:6 Changed 8 years ago by cap
After looking more deeply, you are right in noting that [617] behaves correctly. Unfortunately, we also have [653], which causes the issue I've raised. I see now that the chunk in macros.cs was changed to match the logic of get_reporter_id, which simply returns the authname when the user is not anonymous. Unless there's some good reason for the changes in [653] (which deals with an unrelated problem), I'll submit a patch tomorrow to revert back to the behavior of [617].
comment:7 Changed 8 years ago by daniel
- Severity changed from enhancement to minor
comment:8 Changed 8 years ago by daniel
- Status changed from reopened to new
comment:9 Changed 8 years ago by jonas
- Resolution set to wontfix
- Status changed from new to closed
The reason why the ticket and wiki author is set to the authname instead of the name and email is because it's less likely to change. I think this is the best we can do until we add a user table to the database.
comment:10 Changed 7 years ago by Gunnar Wagenknecht <gunnar@…>
- Cc gunnar@… added
comment:11 Changed 6 years ago by anonymous
- Cc gunnar@… removed
comment:12 Changed 6 years ago by richard.leach@…
- Resolution wontfix deleted
- Status changed from closed to reopened
Is there an easy (e.g. trac.ini parameter) way of reverting to the behavior of having to type in the reporter when creating a new ticket? (Or having a tick box "I am the Reporter"?)
In our setup, we'll often create tickets on behalf of people who will want to recieve email notifications (since they are the real Reporters). Having to create a ticket, then immediately edit it to change the Reporter (and remembering to do so) is a pain!
comment:13 Changed 6 years ago by cboos
What prevents you from clicking the logout link before creating a ticket on behalf of someone?
comment:14 Changed 6 years ago by cmlenz
- Resolution set to fixed
- Status changed from reopened to closed
Please file a separate ticket. AFAICT the issue is not really related to this ticket.



Fixed in [619].