Forum OpenACS Q&A: Categories in BBOARDS

Collapse
Posted by Nathan Reeves on
Has anyone got the Categories maintenance page for the BBOARDS
working successfully??  Its accessed from the Admin page for each
Topic Created.  Whenever I try and access it I get a 500 - Server
Error page load in my browser.  So far I've been creating categories
manually using the command line monitor.

I've checked the CVS Tree on Sourceforge and the page hasn't been
updated in a while.  Has anyone done any fixes to it recently??

Many thanks for a great port.

Nathan

Collapse
Posted by Michael Feldstein on
Nathan, did you ever make any progress with this? We still have this problem.
Collapse
Posted by Don Baccus on
I haven't looked at this since, oh, 2.* or whatever but it used to be a problem in ACS Classic, as well.  We should probably try to fix it for our release.
Collapse
Posted by Nathan Reeves on
I've sent Ben patched copies of the two files (admin-edit-categories.tcl & admin-delete-category.tcl).  Should hopefully appear in the CVS tree sometime soon.

The files only allow us to delete categories with no threads,  addition of categories is not available from these pages.  May be something to work on one day.  Then again, manually adding them to the DB could be good enough to tide us over until the bboard module is rewritten for ACS 4.0 and accordingly ported to openACS.

Cheers

Collapse
Posted by Don Baccus on
Restricting deleting to categories with no threads is fine.

In general, one way to consider handling deletion of stuff like categories (not just in bboard) is to

1. Check for existing items using the category, and provide a means to list them and fix them rather than just output an error message if any references exist.

2. Use "on delete set null" to maintain referential integrity, then
provide a page that lists them so you can fix them.

3. Use "on delete cascade", i.e. delete all the items.  This is dangerous, if every "references" relationship ends up "on delete cascade" then a simple delete can cascade throughout the db getting rid of a lot more things than the admin expected.

So #3 should be used with great care, #1's probably safest, #2 lies somewhere between.