Forum OpenACS Development: Problem with content_item__new() after TIP #42 ...

Collapse
1: Problem with content_item__new() after TIP #42 ...
Posted by Ola Hansson on 06/28/04 03:56 PM
This commit (part of TIP 42, 43, 53 by Timo) has introduced a bug on HEAD.

For example, you will run into trouble if you have an application based on Workflow and your workflow cases are not associated with a cr_item but with a plain acs_object.

workflow_case_log_entry__new() gets called when a new case is created and this function in turn calls content_item__new() (the one with 16 params which then directly calls the now modified 17 param version). The part that causes the error is this, at line 359: 

	   if new__package_id is null then
  	     v_package_id := acs_object__package_id(content_item__get_root_folder(v_parent_id));
  	   else
  	     v_package_id := new__package_id;
  	   end if;
If you try "SELECT content_item__get_root_folder(719);" with a plain object id you will get this: 
ERROR:   -20000: Could not find a root folder for item ID 719. Either the item does not exist or its parent value is corrupted.
Any ideas how this should be solved?

TIA.

Collapse
2: Re: Problem with content_item__new() after TIP #42 ... (response to 1)
Posted by Jeff Davis on 06/28/04 04:11 PM
It probably should check if the parent_id is a cr_item before it tries to deduce the package_id from the root folder, and the workflow_case_log_entry__new should probably propigate a package id down so it does not have to do any of this either way.
Collapse
3: Re: Problem with content_item__new() after TIP #42 ... (response to 1)
Posted by Ola Hansson on 06/29/04 12:48 PM
I have committed a few changes to Workflow which will allow case objects to be plain acs objects.

I can't test the upgrade script on oracle so if someone wants to at least visually inspect it that would be nice.

I figured that workflow_case_log_entry__new() needed to be augmented with the package_id param since by fetching that id inside the function by a call to acs_object__package_id() 'null' would be returned (and the above error would reoccur) if the app at hand stored the package_id in a table of its own as opposed to in acs_objects ...

Should package owners be suggested to move 'package_id' to acs_objects and provide upgrade scripts that will move the existing entries from the package-specific tables?