Redesign CC field

[ludde]

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).

[trac@…]

Certainly a user should be able to delete her own email address from the cc: list.

[mgood]

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"

[robert.pollak@…]

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@…

[Rede]

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.

[mgood]

#1639 has been marked as a duplicate of this ticket.

[Gunnar Wagenknecht <gunnar@…>]

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.

[cboos]

The idea of a check box was resubmitted again in #2399.

Note that FlySpray also uses this method, though the problems raised above are not an issue for them, as you have to create an account and login before being able to submit a "task".

[sergey]

How about this:

1. 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.
2. 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.

[earle at downlode dot org]

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.

[Gunnar Wagenknecht <gunnar@…>]

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.

[cboos]

Marked #2447 as duplicate of this one, among others.

[mjhweb-trac-tickets@…]

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.

[cboos]

#2953 proposed that the CC field could be modelled after the nosy list of RoundUp.

[eblot]

See also #2954

[cboos]

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...

[anonymous]

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.

[cboos]

While addressing this issue, we should maybe take the opportunity to do it at a more generic level than just the ticket subsystem, so that we can apply the Nosy List concept (or similar) to other kind of notifications, like Wiki page changes (see #1660) or new changesets (see #731).

[eblot]

See also #1955 for discarding the notification if the only change on a ticket is about the CC: field.

[anonymous]

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?

[anonymous]

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.

[cboos]

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 or cc_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.

[nexus-]

Might want to consider some JS obfuscater for CC lists as well to prevent e-mail harvesting. :)

[eblot]

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.

[anonymous]

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.

[peter]

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.

[charles.butterfield@…]

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%)

[mahmoud.kassem@…]

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).

[cboos]

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

e-mail

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.

[Waldemar Kornewald <wkornewald>]

That's exactly how I imagined it. Would be wonderful to have this in 0.12.

[ThurnerRupert]

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"?

[cboos]

#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...

[cboos]

Probably an important topic for 0.12 along with other notification refactorings, but I don't see that done for 0.11...

[eblot]

Patch for 0.11 to improve presentation of changes in CC: field

[eblot]

I've attached a patch for 0.11 - as refactoring won't happen before 0.12

This patch is far from being optimal, but it helps removing the useless CC: lines when someone adds or removes an address to/from the CC: field.

[cboos]

Great, but in addition, this should be combined with e-mail obfuscation, a la #153 (using format_author() in the templates).

[cboos]

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.

[ThurnerRupert]

see also #5378 for ajax support.

[Dave Abrahams <dave@…>]

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.

[anonymous]

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.

[Martin.vGagern@…]

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.

[Morris]

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.

[cboos]

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.

[cboos]

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.

[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?

[cboos]

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.

[cboos]

I'm going to finalize the patch this evening. Feedback on the UI would be appreciated!

[osimons]

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.

[cboos]

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:

• #1660 for generalizing the CC: to other resources
• #4056 for notification preferences