EDIT: OK, the issue is that certain folders are not set to allow public access. The top frame’s form has a field that uses @DbCommand(“Domino”; “FolderList”) to get a list of folders, and apparently that will blow up access-wise, even though the user isn’t actually trying to OPEN the folders at that point. So, is there any way around this? Why wouldn’t it just display all the folders, and then ask for authentication when the user tried to open one that didn’t allow public access?
=======================================
I have a web-enabled database that we’re making available online. For reasons mentioned in this post (http://www-10.lotus.com/ldd/nd6forum.nsf/ShowMyTopicsAllThreadedweb/1714b9d4b60409098525741100785867?OpenDocument) we’ve set things up so Anonymous has No Access but all design elements are available to public users. This should allow anyone to browse the database without having to log in, but still allow us to let certain people log in to be able to access hidden columns in certain views.
Here’s the issue: our initial launch on the web is a frameset. The top frame contains a form, the bottom frame contains a page. ALL elements including the frameset are set up Be Available to Public Access Users. However, when we load the frameset, the form in the top frame evaluates to “Error 401 - You are not authorized to perform this operation”. Everything on that form should be available to public access; there are no fields that look up to other databases or design elements that are not public access.
Any ideas why this form isn’t loading without a login?
Subject: Public access issue on web - EDITED
Are you certain this is related to folder access? A web user needs at least Author access to be able to open a form. That sounds like the problem to me.
Subject: RE: Public access issue on web - EDITED
Not if the form is listed as Available to Public Access Users. That’s the fun part - if I type the URL directly of a folder I know is public access, I can open all the documents in the folder. There’s just something funky about this one form.
Subject: Possible workaround for @DbCommand(“Domino”; “FolderList”)
You’re right that it would seem that you should be able to show a list of folders without needing access. However, there seem to be a few similar issues with the subtleties of folder access.
How often does your folder list change? Perhaps you could have a scheduled agent iterate through the list of folders and add them to a multi-value field in a (public) profile document that your form can then use to provide to your anonymous users.
Rupert Clayton
Chicago
Subject: RE: Possible workaround for @DbCommand(“Domino”; “FolderList”)
I had thought of that, and may end up going that route. I just hate to have to use a hack like that when there’s a built-in function that does exactly what I need, if only it would work the way you’d expect it to.
Subject: RE: Possible workaround for @DbCommand(“Domino”; “FolderList”)
OK, I tried this, and I’m still getting the error. I’ve even completely removed all fields from the form, so it’s basically blank. I’m still getting the error. I’m going to try deleting the form and recreating with a different name; this wouldn’t be the first time something got strangely corrupted.
Subject: RE: Possible workaround for @DbCommand(“Domino”; “FolderList”)
Yes, I think you must have some code in a form event that Domino thinks needs authorization not available to a public access user.
I agree that the quickest approach will probably be to create a brand new public access form and then add your elements back on to it one by one until you get the result you want, or at least find out which item is causing the trouble.
Let us know how you get on.
Rupert
Subject: RE: Possible workaround for @DbCommand(“Domino”; “FolderList”)
I started completely over with a new form, and as soon as I add the dropdown list back in (which accesses a public access profile using @GetProfileField), it starts asking for authorization again.
Subject: RE: Possible workaround for @DbCommand(“Domino”; “FolderList”)
Hi again Esther,
So it’s access to the profile and not the folder that’s causing the error.
There are some other posts here that suggest that access to profile documents may be a problem for Public Access users:
http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/3542fbc952f8d4888525704d00598f0b?OpenDocument
http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/e676af000880ef268525710600354dc8?OpenDocument
Is the profile document shared or user-specific?
Any fields of Reader Names or Author Names type on your profile document?
Any change in behavior if you use the LS GetProfileDocument method to access the document?
Cheers,
Rupert
Subject: RE: Possible workaround for @DbCommand(“Domino”; “FolderList”)
Then evidently it’s not a public access profile. What is your evidence for believing that it is?
Use NotesPeek to look at the items of the note. Is there a $PublicAccess item and if so, what is its value?
Subject: RE: Possible workaround for @DbCommand(“Domino”; “FolderList”)
Yes, it does have a $PublicAccess item and its value is “1”. That is my evidence for believing it’s a public access profile.
Subject: RE: Possible workaround for @DbCommand(“Domino”; “FolderList”)
The reason I asked is, with profile documents people often assume that just because they put a field on a form, or check an option on that form, that this is immediately applied to the profile document with the same name as the form, and of course is not generally true – for instance, profiles are most often created by means that don’t involve using the form, and like any document, form changes aren’t applied until you edit using that form.
Is there any other formula or event code associated with the field? Hide formula, perhaps?