> On Jan 20, 2016, at 6:25 PM, Morgen Sagen <sa...@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?
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
