[ic] Can't delete items from UI except as superuser, causes 500

Ed LaFrance interchange-users@icdevgroup.org
Tue Oct 8 12:29:00 2002


At 12:57 AM 10/08/2002 -0700, you wrote:
>This problem was actually noticed not on Items, but on a partial copy of 
>the flex editor as used under the Admin -> Tables area, used to manage an 
>"Articles" section of the site. I can create and edit articles/items just 
>fine, but attempting to delete one causes an Internal Server Error, and 
>the item is not deleted. Nowever, everything works fine as a superuser. 
>it's only as a regular user that the 500 occurrs. Customers can be deleted 
>fine however. After 2 days of working on this problems, and 
>debugging/reverse engineering thru what felt like 100 layers of 
>subroutines, I have narrowed it down to the _hole_call_sv method of 
>Safe::Hole.pm. Unfortunately, I cannot debug past that as it is compiled C 
>code. In short, the Safe::Hole::call method simply calls _hole_call_sv, 
>which in turn calls Vend::Tag, which calls Vend::Parse, which runs the 
>usertag in question (successfully), returns to Vend::Tag, which returns to 
>Safe::Hole. Before returning, _hole_call_sv calls itself (or more 
>accurately Safe::Hole::call) once or twice more (successfully, and there 
>seems to be no pattern as to it calling once or twice), but then the 
>thread dies. No more lines in the error log from any of the Vend modules 
>(almost all debug statements are uncommented). In short, the error appears 
>to be happening somewhere after the usertag returns, but before the 
>surrounding Safe::Hole::_hole_call_sv returns.
>
>Perhaps more importantly, the line that causes a problem is 
>$Tag->if_mm('!tables', "$t=d") in db_maintenance. returning after that 
>line (on either resulting branch) leaves the 500, returning just before it 
>gets the delete running just fine. The installation if IC is pretty much 
>unmolested except for the addition of this copy of the flex editor. I 
>expected it may be my changes causeing the problem until we noticed the 
>same thing happening for Items. The user for which this error occurrs has 
>full permissions on the relevant tables. I have edited the tag to read the 
>more common $Tag->if_mm('!tables','=d') to no avail, as well as several 
>other modifications.
>
>Sorry if this sounds rediculously convoluted and badly explained. After 
>following (often recursive) break marks thru this package for 2 days and 
>having read half the maillist archives and docs i can only think in terms 
>of interchange code and have forgotten how to communicate with humans. 
>that & i think i'm going insane. really hoping someone has had the same 
>problem before and can point me in the write direction. i saw what 
>appeared to be the same problem over a year ago, but it was related to a 
>missing flag tag which is a problem long since corrected.
>
>Using IC 4.8.6 with mysql 3.23.51 on redhat 7.3
>
>please...somebody save what little is left of my sanity.
>
>thanks

Well, you are not insane. I happened to have a 4.8.6 foundation demo setup; 
I changed it to MySQL (which is probably irrelevant with this issue), 
logged in to the UI, created a new non-su admin in the Merchandising group. 
When I logged in as that admin, went to the item list and tried to delete 
something I got an internal server error.

It is just a matter of UI permissions. Log back in as su and edit the 
permissions of the user which is giving you trouble. Ensure that they have 
full permissions on the item editor, and save the changes. Then log back in 
as that user. You should be able to delete items - it worked for me.

Dirty little secret: the foundation demo is never "finished" - there are 
always bugs and blind spots.

- Ed L.


===============================================================
New Media E.M.S.              Technology Solutions for Business
463 Main St., Suite D         eCommerce | Consulting | Hosting
Placerville, CA  95667        edl@newmediaems.com
(530) 622-9421                http://www.newmediaems.com
(866) 519-4680 Toll-Free      (530) 622-9426 Fax
===============================================================