Forum OpenACS Development: 4.6-4.6.1 upgrade script broken?

Collapse
Posted by Lars Pind on
Don, Jeff, and others,

I'm trying to upgrade a site to the latest -r oacs-4-6 from CVS, and I ran into this error on upgrade:

    psql:upgrade-4.6-4.6.1.sql:225: ERROR:  acs_objects_context_id_fk referential integrity violation - key in acs_objects still referenced from acs_objects
psql:upgrade-4.6-4.6.1.sql:246: ERROR:  Cannot insert a duplicate key into unique index acs_objects_pk
psql:upgrade-4.6-4.6.1.sql:284: ERROR:  -20001: membership_rel  violation: Invalid object types. Object -1 (group) must be of type group Object 0 (acs_object) must be of type person
psql:upgrade-4.6-4.6.1.sql:635: ERROR:  CreateTrigger: trigger membership_rels_del_tr already defined on relation membership_rels
psql:upgrade-4.6-4.6.1.sql:659: ERROR:  Relation "acs_privilege_descendant_map_view" does not exist

The first error (line 225) is when trying to delete object 0. Isn't object 0 the object which we grant privileges on for site-wide admins? How do we keep that information through the upgrade? In any event, it seems like there's some data hanging off of this object preventing us from deleting it ...

If you want me to, I can reinstall my dump and try to investigate a bit. I can also give you access to the box.

/Lars

Collapse
Posted by Jeff Davis on
On my postgres install I have content folders Pages and Templates created by CMS with context_id = 0 but no others. Curiously I have those objects in my oracle instance as well and I ran the upgrade script and the seem to have magically been changed to -4 (by the update cr_items set parent_id = -4 maybe?). Anyway, maybe a
select distinct object_type from acs_objects where context_id = 0;
would be illuminating to us.
Collapse
Posted by Don Baccus on
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.

Collapse
Posted by Don Baccus on
Maybe I should hit acs_objects context_id as well as the parent_id in the CR.

I would like to know which type's doing this, though, code shouldn't be setting context_id directly to the security context root.  NULL is the default that says to fall back to the security context root.  Among other things doing this makes objects not depend on a particular value for security context root ...

Collapse
Posted by Lars Pind on
# select distinct object_type from acs_objects where context_id = 0;
  object_type
----------------
content_folder
content_item
(2 rows)
Collapse
Posted by Lars Pind on
# select *, acs_object__name(object_id) from acs_objects where context_id = 0;
object_id |  object_type  | context_id | security_inherit_p | creation_user |        creation_date        | creation_ip |      \
  last_modified        | modifying_user | modifying_ip |  tree_sortkey  | acs_object__name
-----------+----------------+------------+--------------------+---------------+-------------------------------+-------------+------\
-------------------------+----------------+--------------+------------------+------------------
      -400 | content_folder |          0 | t                  |              | 2002-09-19 16:30:35.036186+02 |            | 2002-\
09-19 16:30:35.036186+02 |                |              | 0000000000000010 | Trash
      -200 | content_folder |          0 | t                  |          2561 | 2002-09-02 17:45:40.243961+02 |            | 2002-\
09-04 16:59:56.273853+02 |                |              | 0000000000000001 | Templates
      -100 | content_folder |          0 | t                  |          2561 | 2002-09-02 17:45:40.243961+02 |            | 2002-\
10-23 12:16:56.496424+02 |                |              | 0000000000000000 | Pages
      4195 | content_folder |          0 | t                  |              | 2002-09-19 16:31:42.97926+02  |            | 2002-\
09-19 16:31:42.97926+02  |                |              | 0000000000000011 | ETP
      4196 | content_item  |          0 | t                  |              | 2002-09-19 16:31:42.97926+02  |            | 2002-\
09-19 17:36:48.253738+02 |                |              | 0000000000000100 | ETP
(5 rows)

It seems like it's some old ETP crud that an early and broken version of ETP created, no?

/Lars

Collapse
Posted by Don Baccus on
OK ... I've fixed the minor problem with relational segment permissions and dotLRN works perfectly apparently.

And I've added an UPDATE statement to change context_ids which point explicitly to the security context root to the new value.

I am going to test here before committing, though - I should have this committed by this evening USA west coast time.

Collapse
Posted by Don Baccus on
Ahh ... interesting.  Yes, I assume an old ETP because I ran my upgrade script on a local copy of the current openacs.org contents (which uses ETP) with no problem.

The change I've made to UPDATE context_id will be safe for those old objects ...

Thanks for tracking this down.

Collapse
Posted by Don Baccus on
I checked again with grep (which I'd done earlier) and confirmed that there's no code in our standard packages that sets context_id explictly to zero or security_context_root (via the magic object table.)  content_keywords sets context_id of a new keyword to its parent but it defaults to NULL for the root rather than security_context_object, which is right.

My mistake was to assume that no one had done this in past versions of packages like ETP ... serves me right, I guess!

Collapse
Posted by Lars Pind on
Ok, thanks.

I'll await your fixes, then try to run the upgrade again.

/Lars

Collapse
Posted by Lars Pind on
Now there's another problem, this time with acs-mail:

There are 4 referential integrity indexes duplicated between upgrade-4.6-4.6.1 and upgrade-4.6.1-4.6.2. I'm not sure where they really belong, so I removed them from the latter.

If this was wrong (which the Oracle version seems to indicate, but I forgot to check that before I committed my fix), then please change back.

/Lars

Collapse
Posted by Jeff Davis on
I swapped the index create over to the 4.6.2 upgrade to be consistent with the oracle one.