1. 24 Apr, 2020 1 commit
  2. 23 Apr, 2020 2 commits
  3. 22 Apr, 2020 1 commit
  4. 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
  5. 18 Apr, 2020 5 commits
    • Daniel Vrátil's avatar
      Merge branch 'release/20.04' · fae81064
      Daniel Vrátil authored
      fae81064
    • 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.
      cde208e6
    • Daniel Vrátil's avatar
      IMAP: MoveItemTask: search new UIDs in batches · f33a3538
      Daniel Vrátil authored
      When user moves several hundreds or thousand emails, the Message-ID search query
      would be ridiculously large and rejected by the server. So instead split the search
      into multiple requests.
      
      Luckily most servers support MOVE today, so this code is rarely needed.
      f33a3538
    • Daniel Vrátil's avatar
      IMAP: MoveItemTask - use items() instead of item() · 6d4a9dc1
      Daniel Vrátil authored
      When moving a batch of Items it would generate a warning that
      ResourceTask::item() is being used while there are multiple
      items.
      6d4a9dc1
    • David Faure's avatar
      DAV resource: propagate color changes to the server · b496bf23
      David Faure authored
      Summary:
      The resource didn't implement collectionChanged at all.
      
      Now it does; saving colors work. I realized this meant renaming
      folders didn't work either. But that's for another commit because
      there are dragons due to the tree structure being flattened.
      
      Depends on D28937 to actually trigger the collection modify job.
      
      Test Plan:
      Change color in korganizer, refresh roundcube, it shows the new color.
      
      What I'm not sure about is what "Disable color" is supposed to do.
      The code says "save an invalid color". OK... but what does it mean for the user?
      Right now the calendar just gets some random color instead. What purpose does this serve?
      Why not remove this action, which would remove a submenu i.e. improve usability?
      
      Reviewers: dvratil, ochurlaud, vkrause, winterz, mlaurent
      
      Reviewed By: dvratil
      
      Subscribers: kde-pim
      
      Tags: #kde_pim
      
      Differential Revision: https://phabricator.kde.org/D28938
      b496bf23
  6. 15 Apr, 2020 1 commit
  7. 14 Apr, 2020 2 commits
  8. 11 Apr, 2020 2 commits
  9. 10 Apr, 2020 1 commit
    • Daniel Vrátil's avatar
      POP3: Remove the singleton pattern from Settings · 6cdf43de
      Daniel Vrátil authored
      Summary:
      It's causing issues with the "new" out-of-process settings
      dialog which initializes a new Settings object each time and asserts
      when the SettingsHelper Q_GLOBAL_STATIC is already initialized.
      
      Instead just get rid of the singleton pattern and have Settings
      object be owned by whomever created it and pass a reference to it
      to the classes that need it.
      
      BUG: 419726
      
      Subscribers: mkoller, kde-pim
      
      Tags: #kde_pim
      
      Differential Revision: https://phabricator.kde.org/D28732
      6cdf43de
  10. 09 Apr, 2020 2 commits
  11. 08 Apr, 2020 2 commits
  12. 06 Apr, 2020 3 commits
  13. 05 Apr, 2020 2 commits
  14. 04 Apr, 2020 6 commits
  15. 30 Mar, 2020 1 commit