#1459 closed enhancement (fixed)
Redesign CC field
Reported by: | ludde | Owned by: | Christian Boos |
---|---|---|---|
Priority: | normal | Milestone: | 0.11 |
Component: | ticket system | Version: | 0.8.1 |
Severity: | critical | Keywords: | notification email |
Cc: | wkornewald, robert.pollak@…, shishz@…, subscribed@…, gary.wilson@…, harold@…, weltepe@…, mahmoud.kassem@…, marcandre.lureau@…, Martin.vGagern@…, gt4329b@…, sivaprakash123@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
The CC field sucks, it should be redesigned. It shouldn't be possible for anyone to delete a user from the CC list (unless you are the admin), and the CC list should be a list, not a textbox.
One idea:
For each ticket, there should be a checkbox, "Interesting". Then there can be a new table, cc, that contains the ticket id and the interested user/email, then the "Interesting" checkbox adds/removes the current user from that table. The current user can be read from the session variable. (Works as long as an anonymous user has setup the email in their session).
Attachments (2)
Change History (59)
comment:1 by , 20 years ago
follow-up: 47 comment:2 by , 20 years ago
Yes, I think that the suggestion above meant that people shouldn't be able to remove other users from the CC list. The checkbox would allow them to add or remove themselves from the list.
I agree that a checkbox would be easier for adding oneself to the CC list, though this doesn't actually prevent someone from adding or removing email addresses, since they could simply change their address in the session. If the email addresses were hidden it would make it difficult for someone to remove one since they'd have to guess. However, it could be confusing for someone to figure out how to remove themselves from the CC list if they don't see their email listed.
If we associated the "interesting" flag directly to the user's session, changes in the user's session email would be reflected by the notification, however if a user ended up getting a new session, they would never be able to remove the CCs for their old session.
A variant of this that I would be somewhat interested in is the ability to toggle whether I actually receive notifications on my "interesting" tickets or not. I don't actually use the CC field since I am on the mailing list for getting notifications on all ticket updates, so there's no reason for me to get another update based on the CC list. However, I would like a way to flag certain tickets that I haven't accepted myself, but would like to be able to keep track of tickets that I'd like to review again later. I generally just bookmark them which works ok, but it may be useful to keep track of this in Trac.
P.S. Please don't make useless comments like "The CC field sucks"
comment:3 by , 20 years ago
Component: | general → ticket system |
---|---|
Severity: | normal → enhancement |
comment:4 by , 20 years ago
Cc: | added |
---|
A side effect could be to get better change notification emails. Currently it is difficult to see the actual change when the list is a bit longer:
Changes (by anonymous)
- cc: foo@…, bar@…, baz@…
⇒ foo@…, baz@…, new@…
It would be better to get something like:
Changes (by anonymous)
- cc: removed bar@…, added new@…
comment:5 by , 19 years ago
Well, address field is good and bad. Good because it supports arbitary e-mail addresses in simple straightforward way. Bad because it's error prone. It's very easy (with single keypress/double click etc.) to remove all e-mails from list.
Most open ticket (bugtracking) systems doesn't allow anonymous users to enter tickets, you first have to register somehow, log in and then you can enter. This is bit problematic with Trac since Trac itself doesn't do authentication but relies on external authentication, i.e. by Apache.
One solution is to require authentication for e-mail notifications. That way it would be easy to trac users CC field usage and let then remove/add/change their own CC entries, but not let them to touch anyone elses notifications.
Sidenote: Currently Trac tickets with E-mail notifications can be used as limited free, open and anonymous spam generator. Just enter ticket with spam content and fill CC field.
comment:7 by , 19 years ago
Cc: | added; removed |
---|
comment:8 by , 19 years ago
Cc: | added |
---|
comment:9 by , 19 years ago
There should be different permissions for adding or removing CC addresses. It should be easy for any user to "invite" someone else for commenting on a ticket. However, removing should be only possible for my own email address.
comment:10 by , 19 years ago
comment:11 by , 19 years ago
How about this:
- In the anonymous setup, CC is a list with Add entry field and a Remove button. The entry field is for new emails, the list is for displaying current subscribers, and the remove button is to kick a single subscriber out of CC list.
- In authenticated set up, users can log in, so the interface morphs to do one of the two things:
- Either there's simply a Add Self button, and the rest is the same as item 1 above;
- Or there is a checkbox Watch this Ticket that is calculated according to the value of current CC list; if the user is on CC, the box is checked; checking the box adds the user to CC list.
From usability point of view it's better than a single CC entry field, but not perfect of course. From database point of view, it may still be a comma-separated list in a single column. It's difficult to create a correctly working query show all tickers I subscribe to (bad), but there's little or no change to any other components (good).
If you were willing to change the database, I would of course keep each CC item in a separate row of a separate table.
comment:12 by , 19 years ago
Cc: | added |
---|
comment:13 by , 19 years ago
If you wish to avoid having to deal with permissions, then you could add an email verification mechanism which is triggered when the cc list is changed; the change would not be made until the user replies to/clicks on a link in a confirmation email.
comment:14 by , 19 years ago
The handling of the CC field is not scalable for large communities. Imagine a bug report with 50 CC entries and now imagine a user seeing trac the first time. He could remove all CC entries with one little mistake.
It would be better if there would be an "add cc" field (like Bugzilla has) and a separate list for removing CC entries.
I also think that the template will contain a lot of clutter if the complete content of the CC field is repeated multpile times in the change list (CC changed from … to …). Might be a lot overhead and scolling for CC lists with 10, 20, 50 or 100 users. Currently, 60 CC users will generate 60 (sixty !!!) bug comments (one for each CC add).
I think a verification system is way too much overhead for such a feature. ;) Also, the solution should start small. The permissions arn't really necessary because a user gets notified if someone removes him from the CC list. Thus, he can easily re-add himself. IMO permissions only make sence if you disable anonymous posting, i.e. allow only anonymous viewing and no changes.
comment:16 by , 19 years ago
As a possible extension of this issue, if the control over whether you get email could be extended to include the "notify everyone who ever touched the ticket" list that would be helpful.
Something that happens a fair amount where I work is an issue being assigned to the wrong person (QA misclassifies it, someone makes a mistake in assigning, etc).
However when you then reassign it to the correct person, the original owner still gets notified of every change even when they have no interest or responsibility at all.
Being able to take yourself off that list would be helpful, and seems like it could be part of the same "control notification" feature this ticket applies to.
comment:17 by , 19 years ago
comment:18 by , 19 years ago
Keywords: | notification email added |
---|
comment:20 by , 19 years ago
In #374, I noted that the CC list can be currently seen as an indicator of the "popularity" of a ticket, in a way similar — if not better — than a voting system (as adding your E-Mail involves you a bit more than a simple "fire and forget" +1 vote…).
Therefore, when the nosy/CC list is redesigned, it should be good to still
show at least the total number of people on that list.
Being able to do ticket searches (e.g. nosy greater than xy
)
and ranking on the list length would be even better…
comment:21 by , 19 years ago
Cc: | added |
---|
As stated previously, the danger of being removed from the cc-field is mitigated (as stated in the initial feature request) by the fact that the removal from the nosy-list/cc-field is notified to all members of the nosy-list/cc-field including those just being removed.
From reviewing the above discussions and also thinking about my own needs, and comparing with RoundUp (see #2953 and #2954), it seems that the cc/nosy method is very appropriate for small (probably closed) teams, whereas the "interested" proposal is more appropriate for large (and open) teams.
Would it not be possible to aggregate both proposals by making the interested checkbox for each user effectively a view onto an internally stored (cc/nosy) field, which behaves as the nosy list (auto-add reporter, and owner). Then it can be a matter of configuration as to which view you show users - the "interested" view or the full field.
comment:22 by , 19 years ago
comment:23 by , 19 years ago
See also #1955 for discarding the notification if the only change on a ticket is about the CC: field.
comment:24 by , 18 years ago
Cc: | added; removed |
---|
comment:25 by , 18 years ago
Hey guys, how can I get one of those usernames so that I don't have to expose my email address in the CC field on trac.edgewall.org?
comment:26 by , 18 years ago
Cc: | removed |
---|
comment:27 by , 18 years ago
Cc: | added |
---|
Totally shocking that a system could allow random people to delete others from the CC list. Would it work to just remove TICKET_MODIFY from anonymous. What would be the problem with that? Then the person has to contact the project leader for a login. The leader could assign the new user to a class with appropriate permissions.
comment:28 by , 18 years ago
Milestone: | 0.12 → 0.11 |
---|---|
Severity: | normal → major |
Alec, with the WorkFlow branch, would it be possible to implement a custom field type, which would have the following properties:
- render_view: display an obfuscated view of the e-mail addresses (e.g. s/@.*/@…/), but for those having the TICKET_ADMIN privilege
- render_edit: a checkbox, labelled "Remove me" if the user's e-mail is already in the list, "Add me" otherwise
- action: depending on the id of the checkbox (
cc_remove
orcc_add
), and whether it's checked or not, modify the corresponding (type,id) object (hint: this should apply for Wiki page modifications nosy list as well)
Tentatively scheduling this for 0.11, as it's a highly expected feature and seems a good fit with the WorkFlow changes.
follow-up: 30 comment:29 by , 18 years ago
Might want to consider some JS obfuscater for CC lists as well to prevent e-mail harvesting. :)
comment:30 by , 18 years ago
Replying to nexus-:
Might want to consider some JS obfuscater for CC lists as well to prevent e-mail harvesting. :)
Trac main features should work without Javascript, so IMHO Javascript is not an option for this field.
comment:31 by , 18 years ago
I am using Trac where all users are authenticated, and number of users is very limited (less than 20). There is never any reason to add somebody on CC if they do not belong to that group of authenticated users.
When adding users to CC I'd like to make selection from drop down box just like when assinging ticket ownership, and restrict_owner is used. I need to sometimes add users other than myself on CC.
I also like 'Add Self' button that sergey proposes.
comment:32 by , 18 years ago
Cc: | added |
---|
I like the idea of having a couple text fields to add or remove email address(es). The CC list shouldn't be shown to unauthenticated users (but the number of people on the list should be, as described earlier).
Add CC: [ text field ]
Remove CC: [ text field ]
Then unauthenticated users can add or remove themselves (or even other people, but only if they know the email address of the other people). Once logged in they could see the CC list but at least they wouldn't accidentally be removing people.
comment:33 by , 18 years ago
If there were a way to vote for this I would. Maybe I just did :-)
Hmm, when I hit submit, I got the following response (so I backup up and added this comment): Submission rejected as potential spam (SpamBayes determined spam probability of 85.33%)
comment:34 by , 18 years ago
Cc: | added |
---|
CC field the another way for spam bots to get valid email addresses. Some enchantments should be made to solve that too. Either by preventing unauthenticated from viewing the CC list (peter) or may be the printed CC list could appear as: username at example.com This could be the way for authenticated users too if the registration was open for anyone.
As for the CC field in the form I like the idea of replacing it by 2 fields (Add CC and Remove CC) initially blank. The user could add/remove by writing the email addresses in correct form (username@…)
Using these 2 fields, some options could be added like:
- prevent unauthenticated users from removing email
- Max number of emails unauthenticated users could add (to prevent using trac to send SPAM)
others …etc
Another option to restrict CC to authenticated users only and using their usernames in the CC instead of their emails might be a good idea. OpenOffice.org uses that in its Issue Tracker (a modified Bugzilla integrated into Collab.net).
comment:35 by , 18 years ago
Cc: | added |
---|
comment:36 by , 18 years ago
Rework of this feature could perhaps be done in smaller steps, maybe.
First keep the current way, add some obfuscation to the display of the CC: field and when displaying the field changes (where it should say somebody added or somebody removed, like in e-mail notifications).
Then in a second step, do the rework of the behavior of the field itself. It should be possible to come with a synthesis of all the interesting ideas expressed in the above, as they're converging.
My current stake at it would be to place the nosy list in a dedicated notification
table:
resource | id | level |
This would make it easy to extend the notifications to other "objects" in the system, and would make it possible to get reports about all the tickets where I'm on CC: for example.
Then, on the UI side of things, it would be a simple checkbox for normal users and possibly an "Edit CC: …" button to a dedicated, full-featured, list UI for TICKET_ADMINs.
comment:37 by , 18 years ago
That's exactly how I imagined it. Would be wonderful to have this in 0.12.
comment:38 by , 18 years ago
we use the the owner and cc for work distribution, i.e. owner and cc are set by other persons as well:
- owner is main repsonsible that the ticket gets closed
- cc is additional persons assigned to it
- other users may also enter themselves as cc
- by convention the "working" people know that they should work, you cannot see it out of the fields (except the owner of course).
we also have queries and eclipse mylar trac connector queries to find tickets where one is owner, and where one is on cc, so everybody has a quick overview where his input is required.
therefor i like cboos idea a lot, this would allow (person, role, work-percentage, votes) to cover the following features:
- co-worker on a ticket
- interested/nosy
- voting, allowing to hav max votes per user, where the user might e.g. choose to give all votes to one ticket or 10 to 10 (while just counting entries of the cc has no limitation)
btw, is there voting for such things too … like "cboos as trekkie of the year"?
comment:39 by , 18 years ago
#4720 shows that the current solution, besides being inelegant, also puts a limit on the number of people that can be registered in the CC: list…
comment:40 by , 18 years ago
Milestone: | 0.11 → 0.12 |
---|---|
Severity: | major → critical |
Probably an important topic for 0.12 along with other notification refactorings, but I don't see that done for 0.11…
by , 18 years ago
Patch for 0.11 to improve presentation of changes in CC: field
comment:41 by , 18 years ago
comment:42 by , 18 years ago
Great, but in addition, this should be combined with e-mail obfuscation, a la #153 (using format_author()
in the templates).
comment:43 by , 18 years ago
I just changed my mind, and instead of uploading the updated patch here, I move it on #5126, which is a ticket which can be dedicated to this simple enhancement of the CC: field rendering, as opposed to the complete redesign of the CC: functionality this ticket is about. Please manu follow-up there.
comment:45 by , 17 years ago
Just wanted to add my vote for a simple binary view of a user's Cc: status. That is a hugely important usability feature. I wouldn't be too surprised if that UI change could be accomplished entirely in the template system for authenticated users.
comment:46 by , 17 years ago
Cc: | added |
---|
CC sucks VERY VERY HARD. I just created a ticket with 30 CCs, just because the firefox completion was wrong.
And the damn CC field was full, but I could not notice. Please, FIX the CC field.
comment:47 by , 17 years ago
Cc: | added |
---|
Replying to mgood:
I agree that a checkbox would be easier for adding oneself to the CC list, though this doesn't actually prevent someone from adding or removing email addresses, since they could simply change their address in the session.
If only logged in users were allowed to modify the Cc list according to some configuration, then using the login name instead of the email address could avoid any trouble with changed email addresses.
comment:48 by , 17 years ago
Cc: | added |
---|
I really like any solution for this that makes use of logged-in user data — something as simple and elegant as a "subscribe to mods" link for tickets that you're not watching, and a "unsubscribe from mods" link for tickets that you are watching. Remove the CC field and display altogether.
Of course, that means that anonymous users — or people who don't have/can't get logins — won't have the option anymore to get email updates. Which means that t.e.o. tickets would no longer be sending updates to a majority of the people that want to watch them (like me). Offhand, I don't have a good solution for this anonymous use case.
by , 17 years ago
Attachment: | add_remove_checkbox_for_CC-r6191.patch added |
---|
If TICKET_EDIT_CC permission is not given, then instead of the input field, there's a Add to Cc: / Remove from Cc: address checkbox.
comment:49 by , 17 years ago
Milestone: | 0.12 → 0.11 |
---|---|
Owner: | changed from | to
Please try out the attachment:add_remove_checkbox_for_CC-r6191.patch
I'd really like to finish this for 0.11 so that I can close #153 for real (no e-mails visible anywhere for those who don't have the required permissions).
There's still one bug to iron out in the patch with addresses like "my name <user@host>", but other than that, the approach seems to work well.
follow-up: 51 comment:50 by , 17 years ago
It seems to be a "permission inflation". Maybe have TICKET_ADMIN, and the "Assigned to" of the ticket edit the cc? Or the reporter as well?
follow-up: 53 comment:51 by , 17 years ago
Replying to anonymous:
It seems to be a "permission inflation". Maybe have TICKET_ADMIN, and the "Assigned to" of the ticket edit the cc? Or the reporter as well?
TICKET_ADMIN can already change the reporter info, and the "Assigned to" usually as well in common workflows.
With this patch, TICKET_ADMIN will by default be able to edit the CC: field as an input field, i.e. the 0.10 behavior. The other users can just add/remove themselves.
The TICKET_EDIT_CC needs only to be used by those who want to allow some people (like a "developer" group or "authenticated" users) to be able to edit freely the CC: field, without having to give them full TICKET_ADMIN privileges.
comment:52 by , 17 years ago
I'm going to finalize the patch this evening. Feedback on the UI would be appreciated!
comment:53 by , 17 years ago
Replying to cboos:
With this patch, TICKET_ADMIN will by default be able to edit the CC: field as an input field, i.e. the 0.10 behavior. The other users can just add/remove themselves.
The TICKET_EDIT_CC needs only to be used by those who want to allow some people (like a "developer" group or "authenticated" users) to be able to edit freely the CC: field, without having to give them full TICKET_ADMIN privileges.
Not quite. I see that TICKET_MODIFY
gives me a regular text field. Also confirmed by reading the relevant lines in the patch. For flexibility on public sites - like the Trac site itself, you want people to be able to close a ticket without displaying the full cc: field. I'd go with TICKET_ADMIN
and specific TICKET_EDIT_CC
as only permissions that allow this - like your intended approach.
Apart from that, this looks very nice. Patched, and passed my 10-minute user testing.
comment:54 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Slightly improved patch committed as r6243.
I've taken osimons input into account, and now TICKET_EDIT_CC is only made available through TICKET_ADMIN, not TICKET_MODIFY.
Also, I've re-read the whole ticket and duplicates and I believe the issue can now be safely closed.
The more advanced ideas should be dealt with elsewhere:
comment:56 by , 11 years ago
Cc: | removed |
---|
comment:57 by , 6 years ago
AFAIK, users without the TICKET_EDIT_CC permission should just get a cc checkbox where they can either add or remove themselves from the cc list, as opposed to a text field where they can put a comma separated list of emails. Except my problem is that I want this behavior at ticket creation too. In other words, what's currently happening is that user "foo" doesn't have the TICKET_EDIT_CC, and yet at ticket creation, "foo" can supply multiple emails in a cc text field. Is there a way to make it so that user "foo" only sees a cc checkbox at ticket creation?
Certainly a user should be able to delete her own email address from the cc: list.