evolution-data-server issueshttps://gitlab.gnome.org/GNOME/evolution-data-server/-/issues2023-04-26T14:20:17Zhttps://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/471Evolution isn't searching all locations gpg is configured with to locate PGP ...2023-04-26T14:20:17ZRoy MeissnerEvolution isn't searching all locations gpg is configured with to locate PGP keysI've configured gpg2 via gpg.conf to locate keys from these sources: `local,cert,dane,ldap,wkd,hkps://keys.mailvelope.com,hkps://keys.openpgp.org`
This works, if I use gpg via the CLI, e.g. `gpg --locate-keys "<EMAIL>"` (which uses gpg2...I've configured gpg2 via gpg.conf to locate keys from these sources: `local,cert,dane,ldap,wkd,hkps://keys.mailvelope.com,hkps://keys.openpgp.org`
This works, if I use gpg via the CLI, e.g. `gpg --locate-keys "<EMAIL>"` (which uses gpg2 on Fedora). The key for the address I'm searching for is located on one of the specified key-servers and is imported into my keyring. After using gpg like this, Evolution can use the imported key.
If the key is not in my keyring (manually deleted the key from above from the keyring again), Evolution isn't using gpg as it is configured and is unable to retrieve the key from one of the specified key servers - telling me ~"there is no matching public key in the keyring". This seems wrong to me and I got no idea how to convince Evolution to search for keys on all the locations I've configured.
I'm using:
Fedora 38, evolution 3.48.0 (3.48.0-1.fc38), gpg (GnuPG) 2.4.0
This issue might be related: https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/170https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/170automatically obtain PGP keys for e-mail recipients via keyserver2023-04-24T13:56:39ZDavid Hebbekerautomatically obtain PGP keys for e-mail recipients via keyserverObjective
=========
Evolution should be able to automatically retrieve the PGP keys for the recipients from keyservers. This is apparently implemented by other clients as for example [in Thunderbird with Enigmail](https://emailselfdefen...Objective
=========
Evolution should be able to automatically retrieve the PGP keys for the recipients from keyservers. This is apparently implemented by other clients as for example [in Thunderbird with Enigmail](https://emailselfdefense.fsf.org/en/#step-3b).
This enables the user to encrypt messages to recipients without the necessity to manually check if a key is publicly available. The assessment of trust to the key is a separate issue.
Additional features
-------------------
Ideally the following would be possible:
* The search for keys would start in background as soon as a recipient is defined.
* In case the result of the search is ambiguous, the user is prompted which key shall be used (remember decision).
Background information
======================
This issue may be related to #39.
Reliance on `auto-key-locate`
-----------------------------
It has been [suggested](https://mail.gnome.org/archives/evolution-list/2019-October/msg00052.html) by @mcrha that automatic key discovery with Evolution should be working solely by setting up GnuPG correctly. This would rely on libcamel invoking gpg configured to automatically locate and retrieve keys through [`auto-key-locate`][1]. It has been [observed](https://mail.gnome.org/archives/evolution-list/2019-October/msg00055.html) that Evolution 3.22.6 specifies the recipient in a form (`<local@domain>`), which is not used by `auto-key-locate` for lookups on a keyserver. This has been confirmed with GnuPG version 2.1.18, 2.2.12 and 2.2.17.
To this day it has not definitively been settled if this behavior of GnuPG is intended or not. This is quite uncertain as different parts (see [`auto-key-locate`][1] and [user id](https://www.gnupg.org/documentation/manuals/gnupg/Specify-a-User-ID.html)) of the GnuPG manual are not necessarily consistent. It is at the discretion of the GnuPG developers **if or when** to change the accepted forms (see [bug report](https://dev.gnupg.org/T4726)).
Other approaches
----------------
Certainly other solutions should be possible. For example by altering the form when libcamel is [adding the recipients](https://gitlab.gnome.org/GNOME/evolution-data-server/blob/gnome-3-22/camel/camel-gpg-context.c#L686) to the argument list. As **a workaround [this script](https://gist.github.com/dhebbeker/36b3da99ea1a520ffd9a6ed9b3db7880) can be used** to circumvent the *interoperability issue*.
A compelling solution implementing the [additional features](#additional-features) would probably require to have several different asynchronous calls to gpg.
[1]: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html#index-auto_002dkey_002dlocatehttps://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/380CalDAV: Free / Busy not working with Nextcloud2023-04-17T16:54:10ZClemens SonnleitnerCalDAV: Free / Busy not working with NextcloudI came here because evolution does not show the Free/Busy information provided by our Nextcloud instance. The feature is working without any problems for my colleagues using Thunderbird.
Evolution version: 3.42.4 (by Flathub.org)
Alrea...I came here because evolution does not show the Free/Busy information provided by our Nextcloud instance. The feature is working without any problems for my colleagues using Thunderbird.
Evolution version: 3.42.4 (by Flathub.org)
Already read https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/87 but not sure if it is related.
The nginx access.log shows these two (I think) related entries
```shell
152.21.32.43 - username [10/Mar/2022:16:15:24 +0100] "REPORT /remote.php/dav/calendars/usernameid/personal/ HTTP/1.1" 207 526 "-" "Evolution/3.42.4"
152.21.32.43 - username [10/Mar/2022:16:15:26 +0100] "REPORT /remote.php/dav/principals/users/requestedusernameid/ HTTP/1.1" 404 230 "-" "Evolution/3.42.4"
```
The `requestedusernameid` is the correct one of the user I invited.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/464Setting content type to `text/plain` seems to break camel_cipher_context_veri...2023-04-11T16:05:51ZChris TalbotSetting content type to `text/plain` seems to break camel_cipher_context_verify_sync ()Hello!
I have been working on adding PGP to a program, and I seem to running into a bug in which setting `camel_mime_part_set_content_type` to `text/plain` breaks `camel_cipher_context_verify_sync`. Setting it to `text/markdown` allows ...Hello!
I have been working on adding PGP to a program, and I seem to running into a bug in which setting `camel_mime_part_set_content_type` to `text/plain` breaks `camel_cipher_context_verify_sync`. Setting it to `text/markdown` allows it to work. I have code below that reliably reproduces it. The assertion will go away if ` camel_mime_part_set_content_type (conpart, "text/plain");` is changed to ` camel_mime_part_set_content_type (conpart, "text/markdown");`
"no.user@no.domain" will need a pgp key (I took that name from your test, so that testing pgp key shoudl work).
This is happening in Debian Bookworm.
```
#include <gio/gio.h>
#include <camel/camel.h>
#include <libedataserver/libedataserver.h>
static CamelSession *
chatty_pgp_create_camel_session (void)
{
g_autofree char *chatty_cache_dir = NULL;
g_autofree char *chatty_data_dir = NULL;
chatty_cache_dir = g_strdup_printf ("%s/chatty/pgp", g_get_tmp_dir () );
chatty_data_dir = g_strdup_printf ("%s/chatty/pgp", g_get_user_data_dir () );
g_mkdir_with_parents (chatty_cache_dir, 0777);
g_mkdir_with_parents (chatty_data_dir, 0777);
return g_object_new (CAMEL_TYPE_SESSION,
"user-data-dir", chatty_cache_dir,
"user-cache-dir", g_get_user_data_dir,
NULL);
}
//TODO: Be able to handle encoding attachments
static CamelMimePart *
chatty_pgp_create_mime_part (const char *contents,
const char *userid,
char **recipients,
gboolean bind_recipients)
{
CamelStream *plaintext_stream;
CamelDataWrapper *plaintext_dw;
CamelMimePart *conpart;
g_autofree char *recipient_list = NULL;
plaintext_stream = camel_stream_mem_new ();
/*
* Bind the recipients to the signed message.
* Reasoning: https://theworld.com/~dtd/sign_encrypt/sign_encrypt7.html
*/
if (bind_recipients) {
GString *message_to_sign;
message_to_sign = g_string_new ("Recipients:");
recipient_list = g_strjoinv ("," , recipients);
g_string_append_printf (message_to_sign, "%s\n", recipient_list);
g_string_append (message_to_sign, contents);
camel_stream_write (plaintext_stream, message_to_sign->str, message_to_sign->len, NULL, NULL);
g_string_free (message_to_sign, FALSE);
} else
camel_stream_write (plaintext_stream, contents, strlen(contents), NULL, NULL);
g_seekable_seek (G_SEEKABLE (plaintext_stream), 0, G_SEEK_SET, NULL, NULL);
plaintext_dw = camel_data_wrapper_new ();
camel_data_wrapper_construct_from_stream_sync (plaintext_dw, plaintext_stream, NULL, NULL);
conpart = camel_mime_part_new ();
camel_medium_set_content ((CamelMedium *) conpart, plaintext_dw);
/* text/plain breaks verification, so just make it text/markdown */
camel_mime_part_set_content_type (conpart, "text/plain");
camel_mime_part_set_encoding (conpart, CAMEL_TRANSFER_ENCODING_QUOTEDPRINTABLE);
g_clear_object (&plaintext_stream);
g_clear_object (&plaintext_dw);
return conpart;
}
static CamelMimePart *
chatty_pgp_sign_stream (const char *contents_to_sign,
const char *signing_id,
char **recipients)
{
CamelSession *session;
CamelCipherContext *ctx;
CamelMimePart *sigpart, *conpart;
g_autoptr(GError) error = NULL;
if (!contents_to_sign || !*contents_to_sign)
return NULL;
if (!signing_id || !*signing_id)
return NULL;
if (!recipients || !*recipients)
return NULL;
session = chatty_pgp_create_camel_session ();
ctx = camel_gpg_context_new (session);
camel_gpg_context_set_always_trust (CAMEL_GPG_CONTEXT (ctx), TRUE);
camel_gpg_context_set_prefer_inline (CAMEL_GPG_CONTEXT (ctx), TRUE);
/*
* Bind the recipients to the signed message.
* Reasoning: https://theworld.com/~dtd/sign_encrypt/sign_encrypt7.html
*/
conpart = chatty_pgp_create_mime_part (contents_to_sign,
signing_id,
recipients,
TRUE);
sigpart = camel_mime_part_new ();
camel_cipher_context_sign_sync (ctx, signing_id, CAMEL_CIPHER_HASH_SHA512,
conpart, sigpart, NULL, &error);
if (error != NULL) {
g_warning ("PGP signing failed: '%s'", error->message);
g_object_unref (sigpart);
sigpart = NULL;
goto out;
}
out:
g_clear_object (&conpart);
g_clear_object (&session);
g_clear_object (&ctx);
return sigpart;
}
static CamelCipherValidity *
chatty_pgp_check_sig_mime_part (CamelMimePart *sigpart)
{
CamelSession *session;
CamelCipherContext *ctx;
CamelDataWrapper *signed_dw = NULL;
CamelCipherValidity *valid = NULL;
g_autoptr(GError) error = NULL;
if (!sigpart)
return NULL;
/* camel_medium_get_content () is transfer_none */
signed_dw = camel_medium_get_content (CAMEL_MEDIUM (sigpart));
if (!signed_dw)
return NULL;
if (!CAMEL_IS_MULTIPART_SIGNED (signed_dw))
return NULL;
session = chatty_pgp_create_camel_session ();
ctx = camel_gpg_context_new (session);
camel_gpg_context_set_always_trust (CAMEL_GPG_CONTEXT (ctx), TRUE);
camel_gpg_context_set_prefer_inline (CAMEL_GPG_CONTEXT (ctx), TRUE);
valid = camel_cipher_context_verify_sync (ctx, sigpart, NULL, &error);
if (error != NULL) {
g_warning ("PGP signature verification failed: '%s'", error->message);
goto out;
}
out:
g_clear_object (&session);
g_clear_object (&ctx);
return valid;
}
int
main (int argc,
char *argv[])
{
const char *stream_signed = "Hello, I am a test stream. I should be signed.";
const char *signing_email = "no.user@no.domain";
char *recipients = "recipient1@no.domain,recipient2@no.domain";
char **recipient_array = NULL;
CamelMimePart *sigpart = NULL;
g_autofree char *signature = NULL;
g_autofree char *encrypted_msg = NULL;
g_autofree char *signed_and_encrypted_msg = NULL;
g_autofree char *signed_msg_to_check = NULL;
g_autofree char *signed_encrypted_msg_to_check = NULL;
CamelCipherValidity *valid = NULL;
recipient_array = g_strsplit (recipients, ",", -1);
sigpart = chatty_pgp_sign_stream (stream_signed, signing_email, recipient_array);
valid = chatty_pgp_check_sig_mime_part (sigpart);
g_assert (valid != NULL);
return 0;
}
```https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/165Add backend to access Nextcloud Notes2023-03-23T14:05:11ZMaster OneAdd backend to access Nextcloud NotesI found an [article](https://eischmann.wordpress.com/2017/03/10/nextcloud-linux-desktop/) from March 2017 stating that [Nextcloud Notes](https://apps.nextcloud.com/apps/notes) should automatically be accessible in Evolution via GOA, but ...I found an [article](https://eischmann.wordpress.com/2017/03/10/nextcloud-linux-desktop/) from March 2017 stating that [Nextcloud Notes](https://apps.nextcloud.com/apps/notes) should automatically be accessible in Evolution via GOA, but that obviously is not the case (any more?).
Notes are not listed in the selectable features of a GOA Nextcould account, the GOA Nextcloud account does not show up in the Evolution Notes tab, and it's also not possible to add Nextcloud Notes via CalDAV (when trying to add a CalDAV account and clicking on the button "Search Notes Lists" no results are shown for the chosen Nextcloud account).
I assume something has changed since then, the Evolution Notes tab mentions "Notes Lists" but Nextcloud Notes works with single .txt files (one file per note) in the Notes folder.
So what happened and is there a solution?
I know that I can just access the files in the Notes folder using Nautilus, but it would be a pity to miss out on the integration in Evolution to have it all in one place.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/459Camel: POP3's 'UTF8' command blocking login2023-03-20T09:57:34Zthelazy6Camel: POP3's 'UTF8' command blocking loginCan't receive mails via POP3.
Error banner (german, cannot run in English):
Verbindung mit POP-Server SERVER konnte nicht hergestellt werden.
Fehler beim Übermitteln des Passworts: Datenübergabe unterbrochen (broken pipe)
(Trying to t...Can't receive mails via POP3.
Error banner (german, cannot run in English):
Verbindung mit POP-Server SERVER konnte nicht hergestellt werden.
Fehler beim Übermitteln des Passworts: Datenübergabe unterbrochen (broken pipe)
(Trying to translate back to English: Unable to connect to POP-server SERVER. Error transmitting password: broken pipe)
Was not in previous 3.38.3.
Installation: Fedora 34 Flatpak (3.38.4)
System: Fedora 34/GNOME 40 Wayland/Linux 5.11https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/460evolution | Show tasks with start dates or end dates in calendar2023-03-13T14:23:19ZFD Sevolution | Show tasks with start dates or end dates in calendarIt is more a feature request:
I asked in evolution-client to show "tasks" with their corresponding due-date in the calendar in normal view instead oft a separate todo panel in the side.
And then, giuliohome commented on the discussion ...It is more a feature request:
I asked in evolution-client to show "tasks" with their corresponding due-date in the calendar in normal view instead oft a separate todo panel in the side.
And then, giuliohome commented on the discussion in issue #1644 (https://gitlab.gnome.org/GNOME/evolution/-/issues/1644#note_1695641):
Probably the place to implement this idea is not only here in this repository (in cal-config-google module or the e-cal-base-shell-backend or the cal_comp_transfer_item_to_sync) but also in evolution-data-server.
I'd give a look there at the tasks backend that is returning the I_CAL_VTODO_COMPONENT to check if it can be "cloned" to return also a I_CAL_VEVENT_COMPONENT somehow...
Or otherwise the e_cal_client_get_object_sync...
But, maybe first, can a corresponding "issue" be opened there in the evolution-data-server, to reference this feature?https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/457Split sentence in e-cal-recur.c2023-03-12T13:30:33ZGhost UserSplit sentence in e-cal-recur.cHi, there are a lot of split sentences in e-cal-recur.c
GNOME developers usually avoid this kind of usage.
More information:
https://wiki.gnome.org/TranslationProject/DevGuidelines/Never%20split%20sentences
Some example lines:
- http...Hi, there are a lot of split sentences in e-cal-recur.c
GNOME developers usually avoid this kind of usage.
More information:
https://wiki.gnome.org/TranslationProject/DevGuidelines/Never%20split%20sentences
Some example lines:
- https://gitlab.gnome.org/GNOME/evolution-data-server/-/blob/master/src/calendar/libecal/e-cal-recur.c#L5830
- https://gitlab.gnome.org/GNOME/evolution-data-server/-/blob/master/src/calendar/libecal/e-cal-recur.c#L5835
- https://gitlab.gnome.org/GNOME/evolution-data-server/-/blob/master/src/calendar/libecal/e-cal-recur.c#L5885https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/339Recurring tasks not working properly2023-03-12T09:03:37ZdeesnookRecurring tasks not working properlyIf you set up a recurring task and the start date is not the same as the due date, there won't be a new task upon completion.
example:
start date July 11 2021
due date Aug 14 2021
repetition: every month on the 2d Saturday always
If y...If you set up a recurring task and the start date is not the same as the due date, there won't be a new task upon completion.
example:
start date July 11 2021
due date Aug 14 2021
repetition: every month on the 2d Saturday always
If you check the task as completed, the task should move to the next due date on Sept. 11 2021. Instead, it just remains checked as completed and nothing else happens.
However, when the start date is the same as the due date, it works (in the example: start date Aug 14 2021)~~~~https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/276alarm-notify: Incorrectly handles changes in recurring events2023-02-23T15:16:50ZFranky Van Liedekerkealarm-notify: Incorrectly handles changes in recurring eventsVersion: flatpak evolution 3.38.2 running on fedora 33
Evolution connected to Exchange via EWS.
I've already seen this many times but never got around to reporting this: it seems that cancelled/rescheduled meetings still show the calend...Version: flatpak evolution 3.38.2 running on fedora 33
Evolution connected to Exchange via EWS.
I've already seen this many times but never got around to reporting this: it seems that cancelled/rescheduled meetings still show the calendar alarm on the old date. I just observed the case that no meeting was planned for today at 10:00 (and rescheduled by the organizer for next week, for which I received the corresponding reschedule mail notification) but I still got a reminder 15 minutes beforehand concerning that meeting.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/454libedataserverui: Tweak lookout of the Trust Prompt dialog2023-02-20T09:58:59ZJeff Fortinlibedataserverui: Tweak lookout of the Trust Prompt dialogIn some rare occasions where EDS encounters a TLS certificate problem, when refreshing calendars for example, the user may be presented with something like this:
![Screenshot_from_2023-02-16_16-43-20](/uploads/29c256df27a0f63345e06920fb...In some rare occasions where EDS encounters a TLS certificate problem, when refreshing calendars for example, the user may be presented with something like this:
![Screenshot_from_2023-02-16_16-43-20](/uploads/29c256df27a0f63345e06920fb2e14c3/Screenshot_from_2023-02-16_16-43-20.png)
I don't really understand what is the difference between Cancel and Reject, and while Cancel gets the default action focus, I would suggest that if these remain two separate actions, `Reject` should get the `suggested-action` style class ([to make it blue](https://developer.gnome.org/hig/patterns/controls/buttons.html#button-styles) on GNOME) and more prominent as the recommended action from a security standpoint. Users shouldn't be accepting invalid certificates unless they have a really good reason for doing so.
Furthermore, some other minor improvements that could be made:
* The dialog's title should probably be more descriptive than "Certificate trust..."; could it be something like "Invalid security certificate"?
* "an SSL/TLS certificate" seems to be a linguistic mistake, where "an" should be "a"
* The dialog could benefit from some standard (6 or 12px) padding around the contents (i.e. around everything other than the titlebar), because the icon and text are really close to the edges right now.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/450Support for ProtonMail Bridge2023-01-30T16:17:11ZGhost UserSupport for ProtonMail BridgeHi I'm trying to use PM on ElementaryOS email client but I got "Unacceptable TLS certificate" after using PM bridge credentials
I looked on the eOS mail github and I was referred to page https://github.com/elementary/mail/issues/323Hi I'm trying to use PM on ElementaryOS email client but I got "Unacceptable TLS certificate" after using PM bridge credentials
I looked on the eOS mail github and I was referred to page https://github.com/elementary/mail/issues/323https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/353Inconstistent To: completion in the Mail To: field2023-01-19T06:40:18ZДилян Палаузовgit-dpa@aegee.orgInconstistent To: completion in the Mail To: fieldI have several address books - one local, nine CardDAV books, two offline LDAP, and one online LDAP. All are marked as “Autocomplete with this address book”.
In a new mail window, To: I type `sof`. This is supposed to find: one contact...I have several address books - one local, nine CardDAV books, two offline LDAP, and one online LDAP. All are marked as “Autocomplete with this address book”.
In a new mail window, To: I type `sof`. This is supposed to find: one contact, which has soft in its displayname, one contact in each LDAP address book, the same contact in a CardDAV book (all latter four sources reference the same contact - it has sofi in its display name and in its email address). In addition there is one more CardDAV contact with two email addresses and one of the email addresses contains “sof”. This contact does not have sof in its name.
After I type sof, something no results are found. If I close the window, open it and type again sof, then some of the results are shown. When I type `sof` and no results are shown, I fill to `soft`, then see some proposals, then detele the `t`, then in incomplete list is shown. Everytime I try it, it behaves differently.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/231Release unused memory in factories after certain operations2023-01-18T16:45:00ZDaniel HanrahanRelease unused memory in factories after certain operations**Versions tested:** 3.36.3 on Ubuntu 20.04 and 3.37.90 (flatpak gitecb4ce0) on Ubuntu 18.04
**Description:**
*evolution-addressbook-factory* memory increases by a constant amount upon closing and reopening Evolution client with Contact...**Versions tested:** 3.36.3 on Ubuntu 20.04 and 3.37.90 (flatpak gitecb4ce0) on Ubuntu 18.04
**Description:**
*evolution-addressbook-factory* memory increases by a constant amount upon closing and reopening Evolution client with Contacts tab open (though intermittently). I'm using GNOME System Monitor to check memory usage.
**Testing with 3.37**
In this case I'm using Evolution 3.37.90 via flatpak build. I've imported ~150,000 contacts via CardDAV, and initial memory use for *evolution-addressbook-factory* is 1.4 GiB. Upon closing and reopening Evolution with Contacts tab open, *evolution-addressbook-factory* memory grows to 2.8 GiB, and upon subsequent restarts: 4.1 GiB, 5.5 GiB, and 6.8 GiB (all multiples of approx 1.4 GiB). It does not happen every time, only intermittently.
**Testing with 3.36**
I've tested Evolution 3.36.3 on a fresh install of Ubuntu 20.04 in VirtualBox. I've added no email accounts. I've imported a vCard file containing 2000 contacts via File -> Import...
After import, each time I restart Evolution with Contacts tab open, the memory usage of *evolution-addressbook-factory* grows by ~6.3 MiB each time:
14.4, 21.0, 27.4, 33.6, 40.0, 44.3, 44.4 MiB and stops increasing the next few times.
A while later (~15 mins) I try again, and it increases to 50.7, 57.0, 63.3 MiB and stays at this for further restarts.
Rebooting and repeating the process results in memory usage of: 10.4, 17.0, 23.8, ... 46.1 MiB.
I'd also tested an earlier build last week (3.37.3) with an address book of a few thousand addresses, and recorded memory usage of 9, 37, 57, 77, 96 MiB.
It could indicate a possible memory leak.
In the case of large address books, the increase is very noticeable (At the peak, memory usage for evolution + addressbook processes was 8.5 GiB).
If you need further information/logs, feel free to ask.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/238Cannot delete one occurence of an appointment2023-01-18T10:42:44ZpkzcCannot delete one occurence of an appointmentI have a recurring appointment entry in the evolution calendar. Selecting "Delete This Occurance" from the context menu does not delete the occurance, and there is no notification about errors. When I open the appointment, the "Delete" i...I have a recurring appointment entry in the evolution calendar. Selecting "Delete This Occurance" from the context menu does not delete the occurance, and there is no notification about errors. When I open the appointment, the "Delete" item in the "Edit" menu is grayed.
As for non-recurring appointments, the "Delete" item is grayed for them too, but they can be deleted using the right-click/context menu method.
But not being able to delete a member of a series is really substandard.
$ uname -a
Linux gygv 5.7.8-200.fc32.x86_64 evolution#1 SMP Thu Jul 9 14:34:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ evolution --version
evolution 3.36.3 (3.36.3-1.fc32)
br
pkhttps://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/241task backend suddenly stopped when having bad connection.2023-01-18T10:22:41ZHussam Al-Tayebtask backend suddenly stopped when having bad connection.evolution and evolution-data-server from master branch.
I was connected to the wifi router but the router itself was not connected to ISP when I powered on my desktop. I started evolution but the tasks backend suddenly quit according to ...evolution and evolution-data-server from master branch.
I was connected to the wifi router but the router itself was not connected to ISP when I powered on my desktop. I started evolution but the tasks backend suddenly quit according to an infobar message I saw.
The crash is in /usr/lib/evolution-calendar-factory[gdb.txt](/uploads/3ea87c207389928b8ccc4d1c2b35ca2c/gdb.txt)https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/447Google Task modification not synced2023-01-16T09:52:39ZMassimo-BGoogle Task modification not syncedEvolution 3.44.4
Modifying a Google task description content from the Google webpage is not synced on Evolution. Changing the title or due date is not synced either.
After adding a new task item from the Google webpage, this one get's s...Evolution 3.44.4
Modifying a Google task description content from the Google webpage is not synced on Evolution. Changing the title or due date is not synced either.
After adding a new task item from the Google webpage, this one get's synced on Evolution and then also the old task items have been refreshed to the current content correctly.
I double-checked, it's reproducible here.
I tried disabling/enabling via checkbox of that task list and also context->Refresh.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/424Google Calendar and Task sync is not reliable2023-01-16T09:52:38ZAlex MasidloverGoogle Calendar and Task sync is not reliableThe crux of my problem is that I cannot get Evolution to fully synchronise with my Google Calendars.
Background:
I had a Fedora 36 laptop with Evolution set-up with two EWS (MS Exchange) accounts, a Google account with multiple calenda...The crux of my problem is that I cannot get Evolution to fully synchronise with my Google Calendars.
Background:
I had a Fedora 36 laptop with Evolution set-up with two EWS (MS Exchange) accounts, a Google account with multiple calendars and tasks and one IMAP account - as far as I was aware this was fully working, new events I created on the laptop showed on my phone and vice-versa.
I moved to a new laptop by doing a clean install of Fedora 36 and then copying over my home directory with rsync in archive mode while logged in as root on both laptops so nothing was accessing those files.
When Evolution opened on the new laptop the Google account email, calendar and tasks were showing in the sidebar but my IMAP account and the EWS accounts were missing and all of the calendar entries were also missing.
Eventually I discovered that I had been on Flathub Evolution on the old laptop and when I uninstalled Fedora RPM evolution and installed Flathub Evolution on the new laptop everything seemed to work again.
However, after a little while I noticed that I was not always getting events that I created on my phone appearing in Evolution BUT they were appearing in the Gnome Calendar application - i then spotted there were two copies of every evolution data service program running…
What I’ve tried…
Uninstalling and reinstalling Evolution from each of the 3 repositories and removing and then re-adding the Google account.
Uninstalling Evolution, killing all Evolution processes removing all of the config and cache: “rm -f -R .var/app/org.gnome.Evolution .local/share/evolution .config/evolution .cache/evolution” and then reinstalling Evolution, connect the Google ‘Online Account’ and then starting Evolution.
At one point early on I think I even started with a new home directory and tried to get that to synchronise the calendars.
However, at best, only one of my Google calendars ever has its events synchronised (even though they all show in both Evolution and the Gnome Calendar app and I can click ‘synchronise’ on them in both applications).
Interestingly I can create events on either Gnome Calendar application or Evolution and the events appear on my phone, however, the event created on Gnome Calendar does not appear in Evolution and the event created in Evolution does not appear on Gnome Calendar.
I then tried installing evolution-ews from the command line (which I believe is the correct Fedora way of getting Exchange accounts and a ‘standard’ Fedora build of Evolution.
I briefly had calendars back working but as soon as I restored my evolution data from backup all the calendar content disappeared and disconnecting, reconnecting and refreshing calendars has failed to produce any events from Google Calendar showing in Evolution or in the Gnome Calendar application.
I'm not sure if this is actually a bug (because it may just be a consequence of not having started with a completely 'clean' home directory) or whether it is a feature request for a mechanism to do a complete empty and re-sync of calendar and task entries. Either way I would appreciate some assistance, thanks!
The version I am using is:
`Name : evolution-ews`
`Version : 3.44.4`
`Release : 1.fc36`
`Architecture : x86_64`
`Size : 2.1 M`
`Source : evolution-ews-3.44.4-1.fc36.src.rpm`
`Repository : @System`
`From repo : updates`
`Summary : Evolution extension for Exchange Web Services`
`URL : https://wiki.gnome.org/Apps/Evolution`
`License : LGPLv2+`
`Description : This package allows Evolution to interact with Microsoft Exchange servers,`
` : versions 2007 and later, through its Exchange Web Services (EWS) interface.`https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/448Reminders automatically deleted after 6-7 days2023-01-16T09:28:41ZAntoniReminders automatically deleted after 6-7 daysHi.
## Description
I have an issue since a recent update: now, it seems reminders will automatically be removed after around 7 days.
I'd like to be able to keep them until I remove them manually, as it used to be.
Any way to keep that ...Hi.
## Description
I have an issue since a recent update: now, it seems reminders will automatically be removed after around 7 days.
I'd like to be able to keep them until I remove them manually, as it used to be.
Any way to keep that previous behavior?
## Reproduction
1. Create a new appointment in the calendar at some time in the future.
2. Wait for the appointment time to come.
3. You'll see the Reminders popup show the event.
4. Wait 7 days (you can close the computer if needed, but the window needs to be opened again. I'm not sure if there's a way to do it manually, but one way is to create a new event to make it pop up).
## Actual behavior
The event disappear from the Reminders list after around 7 days.
## Expected behavior
The event should stay in the Reminders list forever.
## Version
I use evolution 3.46.3 on ArchLinux.
Thanks.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/446IMAP: Inbox hidden in offline with "Show only subscribed folders"2023-01-13T07:33:09ZJeff FortinIMAP: Inbox hidden in offline with "Show only subscribed folders"If you have a regular IMAP account (not GMail) set to "only show subscribed folders", even if you have set the folders to download/cache for offline use, starting Evolution without a network connection (or with `--offline`) will result i...If you have a regular IMAP account (not GMail) set to "only show subscribed folders", even if you have set the folders to download/cache for offline use, starting Evolution without a network connection (or with `--offline`) will result in not being able to see that account's inbox folder (you will not see the real inbox folder, and I presume none of its subfolders either) and thus not being able to read the emails offline for those folders.
[This screencast](https://youtu.be/_WJbr-35w_0) demonstrates the problem. I've seen it on all my computers with Evolution 3.46.x (and 3.44 too, I believe), and with various IMAP accounts (not just this one). It seems the key to triggering it is having the "Only show subscribed folders" setting turned on for that account.