On Sat, 2014-10-18 at 15:36 +0100, Graham Cobb wrote: > On 15/09/14 16:19, Patrick Ohly wrote: > > About 1.4.99.4 > > ============== > > > > This is the first release candidate for 1.5. No further changes are > > planned except for fixing yet-to-be-discovered bugs - so find them > > now! :-) > > The (new in this release, I think) checking for mixing shared/unshared > properties is causing me some logical confusion. Here is (the outline > of) how I used to configure my Exchange server config: > > 1) Remove the existing configurations > > 2) syncevolution --configure --template none backend=eas-contacts > database=Contacts username=my-account-name @Exchange contacts > > 3) syncevolution --configure --template none username=my-account-name > password= printChanges=1 loglevel=4 target-config@Exchange > > 4) syncevolution --configure sync=two-way uri=contacts loglevel=4 > target-config@Exchange contacts > > The second step now gives the error: > > [ERROR] per-peer (unshared) properties not allowed: username > > If I remove the username, it gives the error: > > [ERROR] contacts: backend failed: fetching folder list: > GDBus.Error:org.meego.activesyncd.Error.AccountNotFound: Failed to find > account []
That's the expected behavior, and hasn't changed in the 1.4.99.4 release candidate. The new terminology did not change the implementation, just some names. In this case the problem is that "@Exchange" refers to a context, not a sync config, and only sync configs have a username property. You could use "databaseUsername" instead (however, I am not 100% sure whether the ActiveSync backend supports that - WebDAV does), if you don't mind repeating that for each source, ahem, datastore. Or you do as you said yourself and configure the "target-config@Exchange" sync config. When invoking item operations, remember to use "target-config@Exchange" and not just "@Exchange", because SyncEvolution will not automatically use the "target-config" sync config to find username/password. > The only way I can get it to work is if I bring step 3 to be in front of > step 2. That works, but feels wrong (it also breaks my scripts in a > hard to fix way, but that is my problem). Are you sure it used to work? I checked with 1.4.1, and it fails the same way. > It feels like there should be > one of two cases: > > i) The context (@Exchange) is associated with a particular account. In > that case, the account id should be a property on the context, not on > some peer. No, contexts are primarily a collection of sources. These sources can be used in combination with a sync config which then can have additional properties (username/password, proxy settings), but that's not required. > ii) The context (@Exchange) is generic for several activesync accounts > (different users), in which case the folder mappings cannot be checked > at the time they are set up. Not very user friendly. The context could be used like that, starting with 1.4.99.4. Instead of "target-config", user "user1", "user2", etc. with different account settings, then pick those when configuring sources and local sync. The new thing in 1.4.99.4 is that local sync works with target configs not name "target-config". -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
