Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I just upgraded two ancient DocMGR 0.58 instances and while I got most things to work, it seems like the 4th level down in my folder hierarchies is always broken. The first 3 nested levels work fine but as soon as I try any folder on the 4th level, I see an error
"Object not found"
and in the web server logs
PHP Warning: pg_query(): Query failed: ERROR: invalid input syntax for integer: ""\nLINE 5: … FROM docmgr.dm_view_colsearch WHERE parent_id='' AND hi…\n ^ in /var/www/lib/pgsql.php on line 94, referer: http://docmgr.example/index.php?module=docmgr
I suppose I should really see a parent_id there. Any suggestions why I don't? I'm using version 1.2.4 now.
I have now spent several hours debugging this and found that everything seems to go wrong in objectAllPaths() in the DOCMGR object.
I'm not quite sure, yet, why that is but I have found out that one folder in the path suddenly gets dropped when I get to the 5th nesting level which then results in unresolvable paths. It is the third level folder which I can expand in the tree view without any trouble. Only when I try to expand one of its children, do I get the wrong paths. This happens for any folder at this level in my install.
For now all I have is a workaround which might have side effects. I've just commented out line 204 of apilib/lib/docmgr.php which carries a comment "shortcuts".
I'd be very interested in a proper solution.
Turns out that my workaround only seems to catch part of the problem. :(
Meanwhile I have found other errors of the same nature that apply to paths that appear correct (and at least on one occasion even on the first level). This is becoming a real pain in the arse and might mean that I somehow have to keep running 0.58 or the client will complain that their documents have become unreachable.
Hmm, all that function really does is walk back up the tree to get the ids of all objects from the current folder. I'm wondering if a collection is assigned to itself, or something is looping back around. Is there any chance you could email me a dump of the docmgr.dm_object_parent table (just that table), along with the ids of a couple of collections you are trying to browse to that aren't working. I might be able to figure out what's going wrong where with that.
I've sent you the dump and two IDs (don't know of any more just now). As you will see from the dump, the install is huge and there might well be a lot more paths that are a problem.
I had a look at the function as well when I had trhe shortcut problems and saw that it is quite simple. However, while the thing with the shortcuts is annoying, it was at least quite easy to work around. This remaining problem seems significantly trickier.
I have found out that the errors I see after disabling shortcuts are due to trailing spaces in the object names. I haven't corrected those, yet, because I will need to create a rule first to make sure the associated view is updated along with any changes I make. Thus, I don't know either, if fixing this trailing space issue will also fix the problems I had before with shortcuts (which I doubt).
I'll post again once I know more.