GNOME Bugzilla – Bug 313225
Display Unique Symbol For Meetings In Mail Summary Screen
Last modified: 2013-09-10 14:04:09 UTC
Currently email and meetings all get the same symbol in your Inbox, that of an envelope. I understand that meetings = email to Evolution, but it would be nice if the hand shaking symbol displayed in that column for meetings and appointments to give the users a visual cue of the content of their inbox. Just trying to replicate the features we had in GroupWise 4.1 Thanks for consideration, attaching quick mockup.
Created attachment 50571 [details] Mockup of handshake symbol to indicate meetings in Inbox
adding UI keyword.
*** Bug 322041 has been marked as a duplicate of this bug. ***
also see bug 200887
Retarget for 2.7 please?
Created attachment 92044 [details] Example of GroupWise Java client, meeting in Inbox unopened
Created attachment 92045 [details] Meeting has now been opened, icons changes.
After a small investigation about this, open message with every paint and trying to find a part with proper content-type is a performance hit, so I would like to suggest to use a user_flags to store this information. The other problem is that the content-type is not enough, one need to read that part to recognize, if it's a task, meeting or free/busy info (based on e-itip-control.c:show_current) to choose proper icon. What evolution developers think about this?
also see bug #478239
Bumping version to a stable release.
Created attachment 113511 [details] [review] proposed eds patch for evolution-data-server; Necessary part in eds. Notice the change in IMAP. I'm not sure, whether there is something similar required for other providers, like for GroupWise.
Created attachment 113512 [details] [review] proposed evo patch for evolution; How it works: I found out that we set "X-CALENDAR-ATTACHMENT" header, and Outlook invitation has also its header, "CONTENT-CLASS" with value "urn:content-classes:calendarmessage", so if one of these is present, then set the new user flag "$has_cal", and show the meeting icon on every message with this flag. The icon is shown in Attachment column. There is no indication whether user responded to the message or not (maybe we can reuse the Reply icon/flag after any action user does on the message? The envelope icon will be still visible, so it's possible.) Anyway, if none of headers is present, then in time of formatting the calendar attachment in itip formatter, the flag is set, so next time is the icon shown. You should update (read as: regenerate) your summary to see it on all applicable messages, or click one by one. I have no GroupWise test machine, so if someone can test it, then it would be great. Also if some GW invitation can be attached here, maybe from other client...
Akhil, can you test this under Groupwise (both USE_IMAP=1 and without it)
I tried with both group wise and USE_IMAP=1 and it showed different symbol for meeting request. Issues : -> It shows different icon only when i click on particular request. Other wise it behaves as general mail. -> Icon will be displayed for mail which has ics file as attachment. Before i click on particular message, it will show attachment icon but when i click on it, icon will be changed to meeting request icon. -> There are no changes in icon after opening a request as Dave proposed in comment #6,#7 -> Same icon appears in shared memo and assigned task request also though I am okay with it
(In reply to comment #14) > -> It shows different icon only when i click on particular request. Other wise > it behaves as general mail. I mentioned that in the last paragraph of the comment #12: You should update (read as: regenerate) your summary to see it on all applicable messages, or click one by one. I have no GroupWise test machine, so if someone can test it, then it would be great. Also if some GW invitation can be attached here, maybe from other client... It's because the information is stored there, thus it should be regenerated. > -> Icon will be displayed for mail which has ics file as attachment. Before i > click on particular message, it will show attachment icon but when i click on > it, icon will be changed to meeting request icon. I guess this is same as above. > -> There are no changes in icon after opening a request as Dave proposed in > comment #6,#7 Yup, also mentioned in the comment #12 :) ------ What software generated the mail? Was it evolution? If not, can you check whether it contains those headers as mentioned in comment #12?
After a little online discussion with Akhil, it seems the GW client doesn't read any of "X-Calendar-Attachment" or "Content-class" headers, thus it doesn't work on the first read. We will need some GW expert to look at it (I guess it's not so hard, but I do not have the GW test machine thus I cannot test it). The other thing, the icons of new/opened meeting. I used the Attachment column, thus one can see the status of the message in the other column, which shows whether the message was new/seen/answered/... so it is sort of the required behaviour. Maybe, when we will have the proper icons for that, then we can extend it. Dave, I guess, when you mark as unread the message with the meeting in your GW client, then it will show the closed book again, right?
That is correct, when the meeting is marked Unread, the icon should change back. I don't care if a handshake, or book icon is used. In fact, that probably should come from the current theme.
As discussed with David, I tested with an Exchange and it works fine, when I receive new mail with one of the headers, then it marks it with "$has_cal". I also noticed that when replying to the sender, then the status of the message changes as expected, thus either we will need more icons (new/seen/replied) or keep it in an attachment column.
Created attachment 113912 [details] [review] proposed eds patch ][ for evolution-data-server; Same as before, just added part for the GroupWise (Sankar did advice how to do that).
I will suggest to wait until On-disk-summary on trunk (which should not be long from now). I will propose to store the flag in system flags rather than user flags so that it makes it easy to query only specific items, say "Calendar items alone" from the database. There is a msg_type column in the per-folder table, in on-disk-summary facilitating this storage. Not just for meetings, you can have different icons for signed messages, notes, tasks, shared-folders-invites, signed-but-invalid-messages, signed-unverifiable, encrypted-messages etc. The flag_names_t in camel-folder-summary.c needs to be expanded and the appropriate values (or its matching enums preferably) should be filled in the database's msg_type column. It is upto the implementor to decide to give priority in case of conflicts , like: "if we have a meeting which is signed as well, what should the icon show ? meeting or signed ?" Makes sense ?
Marking the patches as needs-work. The patches are good. But it is better to make use of the db features for making it queriable (for other apps.) etc. So, we need to adapt it to disk-summary style. The msg_type column (in sqlite db) patch will be committed in the madagascar branch by today. And, trunk will have on-disk summary running in a few days, anyway.
(In reply to comment #20) > I will propose to store the flag in system flags rather than user flags so that > it makes it easy to query only specific items, say "Calendar items alone" from > the database. Does this mean to add this to the enum CamelMessageFlags? I was thinking about that, but I decided to choose user flags, mainly because of so low number of free system flags. We have there 12 now, and 16 is for folder_flagged, thus only 3 left. That's not many, really. (In reply to comment #21) > Marking the patches as needs-work. The patches are good. But it is better to > make use of the db features for making it queriable (for other apps.) etc. So, > we need to adapt it to disk-summary style. I thought the old and new summary will be interface-compatible, thus no special hacking in each provider whether I'm storing in SQL summary or the old summary. Do I miss here anything? It seems I do...
*** Bug 314772 has been marked as a duplicate of this bug. ***
eds part committed to trunk. Committed revision 9598. evo part committed to trunk. Committed revision 36445. I think I cannot commit this to stable, because this is sort-of an enhancement. Please note that you should either reload old messages from the server to have the icon marked in a mail view, because it is decided in time of the summary filling whether there should be an icon or not, or view the message with an appointment, whereas itip-formatter will mark the message as that when triggered.
Errr, there is a bug in the eds part, when reading data in the summary_build_content_info, I used the last parameter in camel_mime_parser_header, but that was other offset, thus this caused a crash :(
Created attachment 119305 [details] [review] proposed eds patch for crash for evolution-data-server; just fixing the crash, aka additional to the last patch.
Looks correct to me. Approved.
Anticrash patch committed to trunk. Committed revision 9599. Thanks for the review, Matt.