This implies a direct reference to the old security context root, something code really shouldn't be doing. IT's supposed to be the ultimate fall-back object so the site-wide admin always can admin an object no matter how screwed up it is.
I've moved security context root to another magic object (-4, though it doesn't matter) and am using object 0 as a party that maps to the unregistered user (i.e. when [ad_conn user_id] returns zero)
This is a key change in the permissions code rewrite as it allows for the removal of special-case checking for users who aren't registered, in particular it was one change removing the need for UNIONs in acs_object_party_privilege_map and the need to perform a series of SELECT checks in permission_p.
I tracked down references in the CR and the upgrade script updates appropriately. You have apparently found another case where context_id is explicitly set to 0 - could you find out which table contains the reference?
The upgrade script creates the new security context root, updates cr_items with context_id 0 to point to the new root, then gets rid of object 0 and replaces it with a party object. All that's needed is to find what table has the reference and do the same.
