On Jan 20, 2016, at 6:25 PM, Morgen Sagen <sagen@apple.com> wrote:
The .sqlite file gets removed at the end of migrateDelegatesToStore( ), which implies that method completed without error.
Are there delegate assignments in proxies.sqlite to begin with?
Are there still records in your directory service for the delegators and delegates? (migrateDelegatesToStore( ) will only migrate assignments it can locate directory records for.)
Speaking of the directory service — which one are you using? XML or LDAP? Could be some configuration changes need to be made for the new code.
Indeed. I am using an XML Directory Service which -- I am pretty sure -- I have migrated to the correct new format. Unfortunately, I ran bin/calendarserver_upgrade before doing so (which is why the delegate assignments didn't transfer). However, I was able to use bin/calendarserver_manage_principals to re-add the delegate assignments and to verify (using both user:short_name and uid) that they were correct. (I also used psql to check that the delegates table in PostgreSQL was populated with the content I expected*.) Aside from the delegate assignments, is there anything else that bin/calendarserver_upgrade would have screwed-up if (as happened), I ran it before upgrading the XML Directory Service to the new format? * Actually, I have a question about this: In the old .sqlite delegation database, there were SEPARATE entries for read and for write delegates. In the new Postgres table, calendarserver_manage_principals reports that "0" means "read" and "1" means "read/write". Does this mean that I only need one table row to assign someone read/write access, instead of the previous two rows?