1. 07 Jun, 2020 1 commit
  2. 05 Jun, 2020 1 commit
  3. 04 Jun, 2020 3 commits
  4. 02 Jun, 2020 2 commits
  5. 31 May, 2020 1 commit
  6. 29 May, 2020 1 commit
  7. 26 May, 2020 2 commits
  8. 21 May, 2020 1 commit
  9. 17 May, 2020 1 commit
  10. 15 May, 2020 1 commit
  11. 14 May, 2020 1 commit
  12. 12 May, 2020 1 commit
  13. 10 May, 2020 1 commit
  14. 09 May, 2020 1 commit
  15. 04 May, 2020 1 commit
  16. 03 May, 2020 2 commits
    • Igor Poboiko's avatar
      Merge branch 'release/20.04' · a24e6082
      Igor Poboiko authored
      a24e6082
    • Igor Poboiko's avatar
      [resources/maildir] Reload configuraton on configuration change · 4ab1f206
      Igor Poboiko authored
      Summary:
      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
      `mSettings->path()`.
      
      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
      4ab1f206
  17. 01 May, 2020 1 commit
  18. 30 Apr, 2020 1 commit
  19. 29 Apr, 2020 1 commit
  20. 28 Apr, 2020 1 commit
  21. 24 Apr, 2020 2 commits
  22. 23 Apr, 2020 2 commits
  23. 22 Apr, 2020 1 commit
  24. 21 Apr, 2020 9 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.
      9edbb0b7
    • Laurent Montel's avatar
      Minor optimization · c440f03b
      Laurent Montel authored
      c440f03b
    • Laurent Montel's avatar
      Remove unused includes · c98d7a5c
      Laurent Montel authored
      c98d7a5c
    • Laurent Montel's avatar
      Extract messages · 04eab542
      Laurent Montel authored
      04eab542
    • Laurent Montel's avatar
      Remove unused variable · 50e53c79
      Laurent Montel authored
      50e53c79
    • Daniel Vrátil's avatar
      Bump required Akonadi version · 114d9386
      Daniel Vrátil authored
      Require Akonadi 5.14.42 for smooth migration from legacy Google
      resources to the new unified Google resource.
      114d9386
    • Daniel Vrátil's avatar
      Migrator: implement Google Resource migrator · 97c896ca
      Daniel Vrátil authored
      Summary:
      Implement a migrator that migrates the user from the legacy Google Calendar
      and Google Contacts resources to the new unified Google Groupware Resource.
      
      Reviewers: poboiko, vkrause
      
      Reviewed By: poboiko
      
      Subscribers: kde-pim
      
      Tags: #kde_pim
      
      Differential Revision: https://phabricator.kde.org/D28957
      97c896ca
    • Daniel Vrátil's avatar
      639a3670
    • Igor Poboiko's avatar
      [resources] Add a unified Google Groupware Resource · 52113e2f
      Igor Poboiko authored
      Summary:
      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
      52113e2f
  25. 18 Apr, 2020 1 commit