Thanks for the response, I was beginning to think I wasn't going to get one.

...

which forces a login and points them to their home folders, in a folder called "People." We do not see that a login is forced. But you are sure, it is?

Sorry, I missed the fact that the DTML method does not acquire permission settings (explicitly unchecked in the management interface), and is only viewable by an authenticated user. *That* forces the login.

...

.... (Object: Catalog({'meta_type':'Yihaw Folder'})) File /opt/Zope/ZopeInst/lib/python/DocumentTemplate/DT_Util.py, line 334, in eval (Object: REQUEST['AUTHENTICATED_USER'].has_permission('Add EW Nav Links', REQUEST.resolve_url(BASE0+getpath(data_record_id_)))) (Info: BASE0) File <string>, line 0, in ? File /opt/Zope/ZopeInst/lib/python/ZPublisher/HTTPRequest.py, line 724, in resolve_url Unauthorized: (see above) Your catalog contains something that can not be accessed by your user.

Hmm. This seems likely. I didn't write this site, I'm trying to pick up after someone who left the company. I honestly hadn't any idea what "data_record_id" referred to. From what you've said, I've done a little more digging and found that it's the unique identifier which "getpath" needs in order to find a cataloged object. I had no idea the catalog was even involved here, so this provides a whole new avenue to investigate. Thanks!

...

... But from this, I read that AUTHENTICATED USER doesn't have the permission 'Add EW Nav Links' (our own concotion, obviously) I do not think so. "Add EW Nav Links" is the permission that you want to test for. But the "Unauthorized" exception is already raised when the catalogued object is looked up.

Forgive my inexperience, but how do you know this?

...

lacks that permission in 'BASE0+getpath(data_record_id),' which I presume evaluates to the current folder? Each user has a local role of Manager in his/her own folder, which I thought is what the current folder would be. Do you have a catalog in each of these folders or is there a global catalog. With a global catalog, it is well possible that it contains something inaccessible for some users.

Only one global catalog.

I do not know precisely, how "resolve_url" works. Maybe, it checks access rights on its way down to the object. Then, a folder to the object may not be accessible for your user.

That is exactly how "resolve_url" appears to behave to me. It should be checking through all objects in a folder hierarchy, and reporting which ones the permission "Add EW Nav Links" exists for that user. The loop is here: <dtml-call "REQUEST.set('YihawFolders', [])"> <dtml-in expr="Catalog({'meta_type':'Yihaw Folder'})"> <dtml-if "REQUEST['AUTHENTICATED_USER'].has_permission('Add EW Nav Links', REQUEST.resolve_url(BASE0+getpath(data_record_id_)))"> <dtml-call "YihawFolders.append(getpath(data_record_id_))"> </dtml-if> </dtml-in> According to a Chris McDonough email in the archives, "resolve_url uses the exact same publishing machinery as calling a URL through the web; it does _not_ bypass the security machinery. If you do not have enough privledge to access to an object, then you will get an Unauthorized, just like when you call it through the web." Another bit I did not know. Now I can safely assume that there is a "Yihaw Folder" somewhere in the site hierarchy that does not have appropriate permissions set. This also solves the mystery of how the problem was caused in the first place. I do know that my "technically challenged" co-worker was creating some Yihaw folders yesterday. It now appears to me that he made one with incorrect permissions. Am I thinking right here? I'll check it and see. Thank you very much, Dieter! Craig