1. 16 Jul, 2020 1 commit
  2. 15 Jul, 2020 1 commit
  3. 14 Jul, 2020 1 commit
  4. 13 Jul, 2020 1 commit
  5. 01 Jul, 2020 1 commit
  6. 30 Jun, 2020 3 commits
  7. 24 Jun, 2020 1 commit
  8. 20 Jun, 2020 1 commit
  9. 19 Jun, 2020 1 commit
  10. 18 Jun, 2020 1 commit
  11. 17 Jun, 2020 1 commit
  12. 11 Jun, 2020 1 commit
  13. 10 Jun, 2020 1 commit
  14. 08 Jun, 2020 1 commit
  15. 07 Jun, 2020 1 commit
  16. 04 Jun, 2020 2 commits
  17. 02 Jun, 2020 1 commit
  18. 26 May, 2020 1 commit
  19. 15 May, 2020 1 commit
  20. 12 May, 2020 1 commit
  21. 09 May, 2020 1 commit
  22. 04 May, 2020 1 commit
  23. 03 May, 2020 1 commit
    • Igor Poboiko's avatar
      [resources/maildir] Reload configuraton on configuration change · 4ab1f206
      Igor Poboiko authored
      When user adds new maildir, a new resource gets created, with the default
      directory `~/.local/share/local-mail`. Since it's a new resource, with no
      proper configuration, an `attemptConfigRestoring()` is called, which changes
      it to `~/.local/share/akonadi_maildir_resource#`. It's stored inside
      Then a dialog appears, where user can choose prefered directory. It gets
      written to the config file; then `configurationChanged` gets called.
      We call `mSettings->save()`, which overwrites the path provided by user with
      the default one (`~/.local/share/akonadi_maildir_resource#`), making it
      impossible to create a new maildir anywhere else.
      Just use `load()` instead, it makes more sense when configuration was changed.
      BUG: 416287
      CCBUG: 415245
      CCBUG: 415922
      Test Plan:
      1) Create a new maildir resource pointing to `/tmp/dummy`.
      2) The resource gets created, with the name `dummy`. `/tmp/dummy` gets created.
      2) Drop some mails into it via KMail. Mails appear inside `/tmp/dummy`
      Reviewers: dvratil, mlaurent
      Reviewed By: dvratil
      Subscribers: wbauer, kde-pim
      Tags: #kde_pim
      Differential Revision: https://phabricator.kde.org/D27905
  24. 01 May, 2020 1 commit
  25. 29 Apr, 2020 1 commit
  26. 28 Apr, 2020 1 commit
  27. 24 Apr, 2020 1 commit
  28. 23 Apr, 2020 2 commits
  29. 22 Apr, 2020 1 commit
  30. 21 Apr, 2020 6 commits
    • David Jarvie's avatar
      If calendar file is changed by another process, don't rewrite it · 9edbb0b7
      David Jarvie authored
      If another process changed the calendar file, the resource loaded
      the file, and then called reload() (in retrieveItems()), which
      caused it to be written (changing its hash) and then loaded again.
      This patch prevents the superfluous write.
    • Laurent Montel's avatar
      Minor optimization · c440f03b
      Laurent Montel authored
    • Laurent Montel's avatar
      Remove unused includes · c98d7a5c
      Laurent Montel authored
    • Laurent Montel's avatar
      Extract messages · 04eab542
      Laurent Montel authored
    • Laurent Montel's avatar
      Remove unused variable · 50e53c79
      Laurent Montel authored
    • Igor Poboiko's avatar
      [resources] Add a unified Google Groupware Resource · 52113e2f
      Igor Poboiko authored
      This is an attempt to unify existing Calendar&Tasks and Contacts resources into
      a single Groupware resource. At some point, hopefully, GMail support could be also
      added here (see task {T646} and {T9422}).
      Various "subresources" (Calendar, Tasks and Contacts) are implemented as subclasses of `GenericHandler`,
      which is a basic `Akonadi::ResourceBase` interface. The resource decides which `Handler` it should call
      by looking at mimetypes. `Handlers` are `friends` of `GoogleResource`, so they can call its callbacks
      (like `itemsRetrieved()`) as needed. This was done primarily to separate logic of different subresources;
      this might be not the best solution, I'm open to suggestions.
      This patch also reworks the settings dialog & relevant code.
      The dialog is now using `.ui` file. The "account picker" is gone, as it's no longer needed;
      instead, a single "Configure..." button is added which invokes the auth process.
      It also implements "last sync token" API ({T647}) for calendar incremental updates. Without this API,
      event moving between calendars were not handled properly (i.e. event was not removed from the "source" calendar).
      Work to be done:
       # KAccounts integration. Need to be able to `disable` various `subresources` on demand, and determine auth `scopes` based on that.
       # GMail integration. Need to somehow adopt `ImapResourceBase` / `ResourceState` scheme, and merge it with current `Handlers` scheme.
       # Add `Akonadi::Tag` support for Contacts. Tags seem to be more appropriate than having bunch of virtual collections, but this might require some changes inside KAddressBook.
      Test Plan:
      Here's a comprehensive list of what was tested and what issues were discovered.
       # Adding event locally
       # Changing event locally
       # Removing event locally
       # Moving events between calendars locally
       # **Adding calendar locally**
         - new calendar is added as a virtual collection, cannot add events there afterwards; probably a KOrganizer issue
         - color of newly added calendar is not known, google just don't return it to us
       # Removing calendar locally
       # Changing calendar locally
       # Adding event remotely
       # Changing event remotely
       # Removing event remotely
       # Moving events between calendars remotely
       # Adding calendar remotely
       # Removing calendar remotely
       # Adding task&subtask remotely
       # Changing task locally
       # Removing task locally
       # Removing a task with subtasks locally (subtasks go to the upper level)
       # **Adding/removing tasklist locally**
         - wasn't tested, but should work. KOrganizer just don't know how to add a tasklist, it adds a calendar by default (probably it sees no difference between them...)
       # Changing tasklist locally
       # Adding task&subtask remotely
       # Changing task remotely
       # Removing task remotely
       # Adding tasklist remotely (it is not subscribed automatically, however, so user have to go to account settings and enable it)
       # Changing tasklist remotely
       # Removing tasklist remotely
       # Adding contact (including photo) locally, both inside "My Contacts" and "Other Contacts" groups
       # Moving contact between "My Contacts" and "Other Contacts" groups
       # Chaging contact (including photo) locally
       # Removing contat locally
       # Adding contact to contact group locally
         - {D28432} required, otherwise "Link Item" gets silently ignored
       # **Removing contact from contact group locally**
         - wasn't tested, since I've found to UI to "Unlink Item" :(
       # Adding contact (including photo) remotely
       # Changing contact (including photo) remotely
       # Removing contact remotely
       # Adding contact to contact group remotely
       # **Removing contact from contact group remotely**
         - doesn't work: need an easy way to fetch all collections we're linked to (so we know which UnlinkJobs we should start)
      Reviewers: dvratil, mlaurent
      Reviewed By: dvratil
      Subscribers: mlaurent, kde-pim
      Tags: #kde_pim
      Differential Revision: https://phabricator.kde.org/D28560
  31. 18 Apr, 2020 1 commit
    • Daniel Vrátil's avatar
      IMAP: fix use-after free in ChangeItemTask · cde208e6
      Daniel Vrátil authored
      The attribute pointer lives only as long as the owning Collection lives.
      Since the code here was taking the attribute from a temporary object,
      the uidNext() getter called below would return a garbage number.