Forum OpenACS Development: ]project-open[ V4.0 on OpenACS 5.6: OpenACS Upgrade Issues

Hi,

With some delay we have finally committed OpenACS 5.6 into the ]po[ CVS repository. In the next months we'll have to upgrade some 3.000 OpenACS instances running ]po[ at our customers, so we are now looking to eliminate _ANY_ error conditions that might come up. This is particularly important, because most updates will be performed by non-techies who are not capable of interpreting the upgrade error messages etc.

So we are now actually "forking" the OpenACS 5.6 code in order to introduce our changes. Maybe you want to include these changes in to OpenACS HEAD:

- acs-content-repository/sql/postgresql/upgrade/upgrade-5.2.0d16-5.2.0d17.sql:
Malte told me that this "select content_type__refresh_trigger (ct.object_type)" acutally never worked, so we have disabled it.

- ref-countries and ref-languages:
In our system there are already entries in acs_reference_repositories, so we need to remove these in the *-create.sql scripts.

- In several other packages we had to introduce checks if data already existed. For example, the 'ACSObject' service contract already exists in the default ]po[ database from incomplete installations many years ago apparently. So we have to change the "categories-init.sql" installation script to handle this condition.

Concerning an installation of ]po[ on top of an existing OpenACS istallation: We have tested this the last time some 2 years ago with OpenACS 5.4 or so. I don't expect any important issues with that, as we ALWAYS introduce changes from upgrade scripts into the create scripts. However, we usually don't test these updates, so that minor syntactic errors (forgotten ",", ...) may need to be fixed.

Cheers!
Frank

One more thing... Full text search needs ammending for PostgreSQL versions > 8.2. Not sure what exactly has to be done (still in the process of figuring this out), but you have been warned 😊. This talks about intranet-search-pg package, not the OpenACS search package, which works fine.

Hi Eduardo,

]po[ V4.0 has just come out in it's first "dev-1" version with OpenACS 5.6.0 as a base.

I'm now running ]po[ on a PG 8.4 database since a few days for personal development. I've fixed a number of queries particularly in the time sheet system (parts still unchanged since ACS 3.4...), but everything else seems to work.

You'd need to pull the code from CVS though, because we haven't yet released an "update installer" for the current version. The current HEAD is very stable already, we're using it with a major European bank and a few other customers in production...

Cheers,
Frank

Hi Eduardo,

same errors

They are fixed in CVS "HEAD". Please see the instructions on whttp://www.project-open.org/documentation/developers_cvs_checkout. HEAD is pretty stable now, so there is little risk for you.

HUGE issue

Not with ]project-open[ (I believe...). We don't use the permission system in the same way as dotLrn. Permission in ]po[ are mostly _calculated_ at runtime. We use OpenACS permissions just for storing basic configuration information. My development server has only 2700 entries in acs_permissions. Having said all this: We don't have many customers in production yet on 8.4., so there may still be some surprises.

PostgreSQL 9

That will also be a major issue for us, going through several thousand SQL queries... A nightmare. I'm already thinking about a semiautomatic solution.

Cheers!
Frank

Frank,

I'm sorry if I'm asking too many questions here. Please let me know if I should forward it to PO forums.

My system configuration wasn't working somehow, and now I've found the problem: the table im_dynfield_layout is empty.

I was following the isntructions trying to create Internal company and I got the following error:

Error with callback '_form_fill':

When I got to the code I saw that line 1114 in intranet-dynfield/tcl/intranet-dynfield-procs.tcl having the following operation:


db_foreach attributes $attributes_sql {

# Check if the elements as disabled in the layout page
if {$page_url_exists_p && "" == $page_url} { continue }
(...)


This query is making that object_type var is set to null value. I've dig into the SQL files and I couldn't find insert in default layouts for im_companies. Did I miss something?

I can also see this message in my /intranet-dynfield/ URL:


There are invalid DynFields in the system for the following object types.
These DynFields won't be shown.
im_company: default_bill_template_id
im_company: default_delnote_template_id
im_company: default_invoice_template_id
im_company: default_payment_days
im_company: default_payment_method_id
im_company: default_po_template_id
im_company: default_vat
im_invoice: canned_note_id
im_material: file_type_id
im_project: final_company
Please check these DynFields and make sure that every DynField has a "Pos-Y" value
by editing the DynField and specifying a value. You can use '0' as a default.


Can you give me any guidance on this?