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 [] 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). 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. 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. To me, option (i) seems more logical as well as much more user friendly. But then the account can't be a per-peer property (which peer do you use?). This might be because we are misusing the username property to provide a convenient way to specify the activesyncd account -- although I don't really understand what is wrong with that. I also don't understand how other backends deal with similar problems. Surely a Google server is accessed using some credentials and they are either properties of the context or the peer, with the same issues? We could, of course, just stop using username and embed the account name in the database name. It would be a bit tedious to type (as account names are usually actually email addresses, although they don't have to be). There seem to be two problems here: 1) There is a change which will force people to change the way they configure ActiveSync accounts. Can/should we do something to allow existing configs and/or existing configuration scripts to work? 2) How do we actually want it to work in the future (maybe an issue for the next release)? Graham _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
