Document has been deleted... But it hasn't!! 1

[fishkake]

Hello guys... Or should I just say hello Pascal - he's the only one who's replied ot me on here so far!!

I have a system which sends doc links in emails. After a few cycles, these doc links don't work, because they say the document has been deleted. I assume this is because the document has been changed, but how can I solve this problem? It only happens after a FEW saves, not after the first one, which is weird...

Any ideas?!

 

[pmonett]

Doclinks are always made on the UniversalDocumentID, which does not change when editing a document.
So the issue is not link-related, If the error message says the document was deleted, then it has to mean that the docID initially referenced is no longer available at all.
If the document is not accessible to the user, it is either because it has indeed been deleted, or the user no longer has reader or author access on it.
So, do your documents have any special access rules, any Reader fields with user-managed lists ?
Other question, do you do versioning on your documents ? You state that "after a few saves" the link no longer works. Could versioning and removing the oldest version have anything to do with it ?

Pascal.

 

[fishkake]

There's no versioning, but my document-level access rights are held together by very thin thread, so I guess thats it...

I've run a few tests now, and I think I've just been doing things too fast - there's an agent which takes care of access, and I think I just hadn't given him time to do his job!

 

[pmonett]

I believe we have already talked about the perils of Reader fields and their management.

You would be wise to remember the suggestions I made on that subject before even the server no longer has access to your documents .

Pascal.

 

[fishkake]

As long as the server is a Manager, I'm OK aren't I? I thought you couldn't lock Managers out...

 

[pmonett]

ALERT ! ALERT ! ACL and document access have NO RELATION !

Manager is just a level of access to the database itself. The ACL defines what you can do WITH THE DOCUMENTS YOU CAN ACCESS. It is the document itself that defines if you can access it or not.

I have designed databases for HR departments which specifically do not allow anyone but HR personnel to "see" the documents that are in there - the database administrator (an IT guy) may have Manager access, but he can only allow other HR people to access the database. From that point, an HR person already certified in the db must certify the newcomer in order for that person to see the documents.
In that particular application, the IT guy did have Manager access, but he couldn't see any document at all. And he couldn't modify the design either, because the server copy was design locked and the HR department was sole retainer of the template.
Of course, the whole thing was rather bloated with security code left and right, and it was a dog to use, but after all the discussions during specification phase, that was what they wanted.

You can lock anybody out. All it takes is a bad update to a Readers field (i.e. wrong spelling) and no other backup entry and your document will not be readable by anybody - including the server.
That means that you will not be able to use the server id to browse the database and find the doc (difficult anyway, since the server itself has to be down to be able to use the ID), nor will an updated replica show the document anymore - it will have been erased during the replication process.

The ONLY sure-fire safeguard is to implement a special Reader field that no code modifies - if the document is to be restricted, that is. Which, of course, means that you DO need a bit of code to empty that field if the doc goes public, and another bit to reinstate its value if the doc is restricted again.

Pascal.

 

[fishkake]

You're right, you have told me this before... Its kinda hard to get your head around Notes Security sometimes!!

Security isn't such a big deal in this system, so I've put an Author field (hidden) in the database, which contains the name of a "Database Administrator" taken from the Profile document. The form which edits the profile document will not allow this field to be empty, so there will always be somebody who can edit!

Plus, if all else fails, and we lose access to some documents, it wouldn't be a crisis to copy the database design into a new one - the workflows are important, but when they are finished the documents are not critical. Its always pleasant to work with such lax systems!

 

[pmonett]

If you do not use Reader fields, then there is no danger of losing access to a document.

Author fields work a bit differently. If there is no Author on the document, then you need to have at least Editor-level access in the ACL in order to change it. If your name is in an Author field, then you only need Author-level access in the ACL to change it.

In this manner, you can see that Author fields work in reverse of reader fields. With Author fields, if it is empty it prevents your editing (unless ACL privileges override Author privileges), whereas empty Reader fields allow all to access the document. On the other hand, an Author field with a name that is not yours will not prevent you from accessing the document, whereas a Reader field with a name that is not yours will keep you from even knowing that the document exists.

Pascal.

 

[fishkake]

Monsieur Pascal, are you still here?

NOw I have a problem not explained by the above - the document links are telling me that "The linked document cannot be found in the view", and yet if I open the database manually I can open the documents - I have access, so why aren't the links working?

I've just given you a star for this post - if you'd rather start a new post and get a new star, feel free. I just couldn't be bothered.

 

[fishkake]

I've been a complete idiot.

I was sending the mail from a dialog box, and the link was to the NotesDocument in the dialog box, which ceases to exist once the dialog box is closed.

I now have a new problem, but I've put it in a seperate thread.