GNOME Bugzilla – Bug 346146
Appointments in GW Sent Items Should Not Display Accept/Decline Buttons
Last modified: 2009-06-19 14:24:08 UTC
Please describe the problem: A message in the Sent Items folder should not display the Accept/Decline/Tentative buttons. Only the message in the Mailbox should have this section of UI. Sent Items are for tracking only, and not for accepting and declining meetings. In 2.6, the buttons don't even work correctly. They add the item to your UI only and not the backend database. When you exit Evo and re-open those that have been accepted from the Sent Items box are gone from the calendar. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
This is how the itip-fromatter currently is implemented. Its a good idea to implement this - reassigning to calendar/chen.
Created attachment 96167 [details] [review] proposed evo patch for evolution; it disables bottom buttons/items if the message is in Sent, Trash, Drafts or Outbox folder. It's a bit longer, but only because of indenting, not because of too much code change.
Milan, Your approach is right, but still it doesn't fix it because, I dont think GW goes by the CAMEL_FOLDER_FLAGS. They do straight string compare of folder name IIRC. Sankar?
This patch should work. Srini: He is doing a EAccount sent-folder-uri comparison. This is different from the CamelFolder flags thing.
Committed to trunk. Committed revision 34347.
I don't have a separate "Sent" folder. Instead I have selected my inbox also as the "Sent" folder. The usage of that is: * grouping/threading mail and corresponding reply * marking sent email for follow-up in the same folder as incoming mails * archive mail+reply together in some other folder The check that disables the itip formatter for the "Sent" folder therefore isn't suitable for me. I want the formatter enabled in my inbox and in all other normal folders (because at work I also archive meeting invitations in a separate folder automatically via a filter rule). Any suggestions how that can be achieved while still disabling the formatter in "pure" sent folders? Note that I don't use Groupwise. I'm using normal local mail folders and calendars.
I think it just recognized that the folder is a sent folder, thus doesn't show the buttons. I do not know how to solve this in general... Maybe more checks...
If there is no check that can determine whether a folder is also used as inbox or normal folder (and I think such a check is not possible), then in my opinion the check for "folder is sent folder" should be commented out: it might inconvenience people who look at their "sent" folder, but they can simply ignore the additional buttons. On the other hand, people who have a setup like myself cannot access the buttons unless they move the meeting request, which is extra work.
Created attachment 118084 [details] [review] proposed evo patch for evolution; I think this is sufficient and will work for you and for other people as well.
Milan, you mustn't call camel calls on main thread. This func executes on main thread.
OK, I forgot this (didn't realize). Any idea how to do that? It will be quite hard and ugly code to work with this.
Created attachment 127265 [details] [review] proposed evo patch ][ for evolution; Checking for an Inbox is mostly done as I did in this patch, by its name. I cannot think of any other approach, not involving any ugly multi-threading code.
Just spoke with sankar and jony on this. Groupwise has the name for Inbox folder as Mailbox. Any other provider may have a different name for inbox too. Can Inbox also be a translated string ? It would be better to implement this flags.. IMHO sankar/srag what would be better solution for this.. ?
The best solution will be to have the ability to access folder flags without having to do a camel_store_get_folder_info I suggested to srag some time back about this and he was having some different opinions on that. We never got to discussing that again. Such flag code will allow us to nicely do: - show recipients instead of sender for sent-items folder (remote) - enable retract, track-status etc. for sent items folder (provider specific) - + other such benefits we have added a lot of hack in lot of places by comparing folder names. It will not work in servers configured in differetn locales etc. We should get rid of all these hacks and do the basic flags thing. The flags thing should be easy to implement we just need to discuss if there are any shortcoming with that approach before we begin.
BTW, there is a hack for fixing this bug. We can compare folder name with sent items and disable the accept/decline items. So you allow accept in any other folder except sent items. If you compare with inbox, you will not get accept/decline for appointments which are moved to other folders, as a result of a server side rule.
Sankar wrote: > BTW, there is a hack for fixing this bug. We can compare folder name with sent > items and disable the accept/decline items. So you allow accept in any other > folder except sent items. Isn't that leading to the problem I mentioned in comment #6? If the configured "sent" folder is my inbox, then I wouldn't be able to accept invitations there.
(In reply to comment #16) > Sankar wrote: > > BTW, there is a hack for fixing this bug. We can compare folder name with sent > > items and disable the accept/decline items. So you allow accept in any other > > folder except sent items. > > Isn't that leading to the problem I mentioned in comment #6? If the configured > "sent" folder is my inbox, then I wouldn't be able to accept invitations there. > nope. What I meant is an ugly hack. which will do: strcmp (folder->full_name, "sent") which will disable the buttons in "sent items" . But that is an ugly hack which cannot be in the Gnome svn and fit for only a community repo. We will maintain sanity in the svn. The right fix will be to get flags for a folder. It should be easy to implement also. We will take up this discussion once srag is back from vacation.
(In reply to comment #13) > Just spoke with sankar and jony on this. Groupwise has the name for Inbox > folder as Mailbox. Any other provider may have a different name for inbox too. > Can Inbox also be a translated string ? It would be better to implement this > flags.. full_name should not be translated, it's a privilege of 'name' member, I believe. Nonetheless, if GW has a different name, then forget it, it's wrong. That all was only because of the mentioned lack of folder info's flags in a CamelFolder structure. I agree with Sankar that we should have such thing in a CamelFolder, it'll simplify so many things.
> full_name should not be translated, it's a privilege of 'name' member, I > believe. It will not be. But if the server is installed in a different locale than English, I have heard that the name field is also translated. But the GroupWise server sends flag to identify the folder type. We just have to get and use it in evo.
Err, some providers seem to be easy, but others are just insane, like getting path and scanning directory structure, just to obtain correct flags. I tend to WONTFIX as the amount of changes doesn't worth this bug. (Maybe it'll be used later/elsewhere too, but at the moment...)
This patch already exists in SLED 11, we just need to get it merged into the upstream build.
Dave, the patch was not taken into sled since it was a hack and we want to do it in a better way in upstream.
I just added a function in mail_folder_cache_get_folder_info_flags to access the flags from folder tree itself instead of making costly camel calls. Will see if the same function can be used here to fix the issue.
Created attachment 136934 [details] [review] proposed evo patch ]I[ for evolution; Thanks Chen, the function you added helps here soooo much. :)
This should take care of all the cases :)
Created commit 4a2d5ee in evo master (2.27.4+)