Hi folks,
Been dealing with this on and off for a long time, and I’m at the end of my rope. I’ve seen similar questions, and I’ve read (and tried) hundreds of possible answers across this forum and the R5 forum. If anyone can think of any other suggestions I might have missed, I’d love to hear them.
The basic problem I’m having is that in one particular Notes application, certain documents are now issuing the dreaded “You are not authorized to perform that operation” error when anyone tries to save changes to them. Once that happens, they seem to be permanently locked out from any modifications. I with Manager access can’t seem to do anything to save changes, either through the front or back end (ie. via a quick agent to modify a field value). And no, there are no readers/authors fields in the entire app. For whatever reason, the database refuses to authorize anyone to modify these documents.
Some details:
-
My users have Editor access to the database. I have Manager access.
-
*** There are NO readers or authors fields in the entire database. *** I’ve used NotesPeek and other tools to make sure there are no readers/authors fields on the affected documents.
-
It happened on R5 servers with R5 clients, and has now started happening on our R6.5 server (still accessed by R5 clients. R5.0.9 to be precise).
-
This is a Notes client-only application. There is no web access to it.
-
It is (so far) unpredictable which documents will be affected, or why. There are many thousands of documents in the database and “most” are fine.
-
Replicating the database locally, deleting the server replica and then re-creating the server replica from local seems to be the only fix the problem, but sadly it only works temporarily. The problem starts cropping up again within a matter of a few weeks.
-
I’ve tried modifying the ACL in hopes that there was some kind of a corruption issue, but that hasn’t seemed to help.
-
I’ve tried rebuilding view indexes, to no avail.
-
Restarting the server doesn’t help either.
-
Out of desperation I once tried ADDING an authors field to the appropriate form to try to remind the database that I do have access to save, but that didn’t work.
Can anyone think of anything else I might be able to try?
Thanks for the help,
-SB
Subject: Users can’t save documents (no readers/authors involved)
Are you using the same hardware (server) on R6.5 as you used on R5?
Subject: RE: Users can’t save documents (no readers/authors involved)
Sadly, no - we moved to new server hardware when we upgraded, I forgot to mention that. It doesn’t seem to be related to server hardware, server software, client hardware or client software - at least not as far as I can tell. Definitely an application issue, but I can’t figure out where…
Subject: Users can’t save documents (no readers/authors involved)
There’s 2 things I would check for …
Turn on the Script Debugger and then try to save a problem document.
Are there scripts running in QuerySave / PostSave that might be causing this message ?
Are there are $Seal items in these documents ? (Someone might have encrypted them.)
I’m betting on number 2 
If they do have $Seal items, then the last person to have saved them performed the encryption, probably through the document properties. (This can be done on a user level, and does not have to be built into the database design.)
Subject: RE: Users can’t save documents (no readers/authors involved)
#1 - I’ve tried running through the debugger, and everything’s fine up through the end of the QuerySave. The PostSave never executes. However, since I can’t modify the documents via an agent either, I know it’s not a problem in the UI code… (Not “just” in the UI code at any rate.)
FYI the details on error I get when I try to run a little agent on a problem doc (FIELD temp := “1”) explicitly say that my ID is not authorized to modify document . Except it is, and there doesn’t seem to be anything wrong with that doc when I look it up by NoteID in something like NotesPeek. Sigh.
#2 - Oooh, that sounded like a great idea! Unfortunately, it doesn’t seem to be the case - I don’t see any $Seal items in the problem documents. Thanks for the suggestion, though!
Subject: RE: Users can’t save documents (no readers/authors involved)
Humm…I can’t think of anything else.
Take a look at the document properties, security tab - any values in either of the Encryption Key fields ?
Try this - take a design-only copy of the database. Copy-and-paste in one problem document. Does the issue still exist with that copy ?
If so, I’d be willing to take a look at it for you - make the default access Manager and send it to GrahamRichards[at]ca.ibm.com
(Replace the [at] with @ … anti-spam
Subject: RE: Users can’t save documents (no readers/authors involved)
Hi Graham,
Neat, I don’t think I’ve ever really paid attention to the encryption key area of that tab before. (Learn something new every day?) Sadly, none of the docs have any values in there. When I tried to put a value in Public Encryption Keys field, I received the “You are not authorized to perform that operation” message on the bad docs, and it went through fine (and added the $Seal field) on the good ones.
One other bizarre thing - calling a StampAll on a document collection containing the bad docs doesn’t fail, and DOES update the docs with the new value. I almost fell out of my chair when I realized that. It doesn’t “fix” the docs - you still can’t edit them any other way even after the StampAll - but it does work on its own. Strange.
I did try your suggestion of creating a design copy and pasting in some bad docs, but they (of course) behaved themselves just fine in the copy. I figured that would be the case though, since replicas of the bad docs also work fine in their new replicas. (I just can’t replicate any changes back up to the production database. No error message, just no changes sent.)
Thanks for the suggestions though, I really appreciate it. I’d be happy to find out I was doing something silly, if it meant I could take care of the problem once and for all. Unfortunately, it just feels a lot like a “random” problem that might not be completely resolved until I can rewrite the application someday. But if you can think of anything else in the meantime, I’m all ears!
Thanks again,
Stephanie
Subject: RE: Users can’t save documents (no readers/authors involved)
I would say you’ve definitely got some corruption going on in the database then. I’m not an administrator, but you might want to have yours try running some of the “fix it” commands on your database, and check their logs for any funny messages.