Hello all:I have a form with a rich text field to create an attachement in ,I need to check if the user realy attached a file to the form or not,then I need to disable edit and delete for any user
is there a way to achieve this
Thanks
Dalia
Subject: How to detect attachement existance
Formula language:@Attachments > 0
LotusScript:
notesDocument.hasEmbedded
Subject: RE: How to detect attachement existance
Thanks Morten for your usual help,what about disabling the edit and delete for the attachement
Subject: RE: How to detect attachement existance
With regards to preventing editing the document, you have two options:
Provided all “ordinary” users are ACL Author, and the document has an Authors field, containing the user (author name), you could simply remove the user from the authors field.
I suggest having a Computed when composed Text field that records the original author (Call it “CreatedBy”), formula: @UserName
The Authors field should be Authors, Computed, with a formula similar to:
@If(@Attachments = 0; CreatedBy; “”);
Which would simply remove editing permissions for the user once the document has been saved with an attachment. A convenient side-effect is that Deletion is also removed.
Note that this method if fail-safe, and still allows users with Editor (or higher) ACL access to still edit/delete documents, thus allowing admin access.
Alternatively, you could use a more involved method:
Enter LotusScript code in the Form QueryOpen event and set Continue=False if Edit mode is requested by a non-admin user on a document with attachments. Enter similar code into the QueryModeChange event to prevent users from switching to edit mode.
Finally, you’ll have to catch deletions by entering LotusScript code into the Database event QueryDocumentDelete.
The problem with this last method is that it is not fail-safe. A user can circumvent the code by simply enabling the debugger, and exiting out of thye event handlers, or simply write an agent that performs the deletion.
Hope this is enough to get you going. If you choose the Form event method, search the ND4-5 forum for examples http://www-10.lotus.com/ldd/46dom.nsf/Search?SearchView&Query=queryopen%20and%20querymodechange%20and%20"continue%3Dfalse"&SearchOrder=0&Start=1&Count=100
Subject: RE: How to detect attachement existance
Your users need to be authors. You need to have an Authors & Readers field on the document, which is set/changed once the attachment has been added. These fields should not contain the name of the user once they’ve done what they need to.
This will stop the document from being able to be edited, and the attachment won’t be able to be edited/deleted either.
HTH,
Ranjan
Subject: Why Readers?
No point in having a Readers field, unless you want to prevent users from seeing their own documents containing attachments.I understood the requirement to just prevent editing.
Subject: RE: Why Readers?
Pedant! 
The readers field is up to you - in my mind the applciation you talk about is more complex - which is why I mentioned the readers field. The readers field can do more than lock out users from their own documents - they can also refine access so that other users can/cannot see document not created by themselves - but that’s down to your design.
Cheers,
R
Subject: RE: Why Readers?
OK, I just wanted to make certain that we didn’t make things more complicated than required. And since the requirements were to prevent editing, I didn’t see the point of mentioning Readers fields.
I live by the Extreme Programming rule: “Do the simplest thing that could possibly work” and “Always implement things when you actually need them, never when you just foresee that you need them.” Extreme Programming Rules
Subject: RE: Why Readers?
It’s a thankless task helping others - most of the time you have your hand bitten off. Ritous are those who never preach to helpful souls.
Yes - but that assumes that I have detailed knowledge of your spec. The extreme programming rule (as interpreted by you) can be seen as a rule for cowboys who develop systems that are not future proof, and not scalable. But mthinks that Extreme Programming doesn’t mean that your solution cannot be scalable.
Ever built a system which needs to be updated after the event with readers fields - this can cause issues with replication, document updates, etc. etc. Which means that you should be aware of every pitfall in your design concept, and allow for future proofing. That doesn’t mean that you create huge code modules that you think you might need in ten years - but simply apply simple models (eg. for security) which will work regardless of which way you turn.
Anyway, I’m bored of this debate (already), and good luck with your ‘extreme programming’. In future, may I suggest that you try and look at the Designer help before posting your question here.
BYE!
Subject: And what exactly am I going to find in designer Help?
I think you are barking up the wrong tree, here.
I wasn’t the one asking the question in the first place.
Subject: Ignore last paragraph
OK - so ignore the last paragraph (my mistake).
But my points about ‘extreme programming’ are still valid. Methodologies are there to guide…but you can interpret them as you like - it’s a free world…but don’t be a cowboy! That get’s me mad, cos it’s cowboys that gives the Notes/Domino environment a bad name!
‘Mental bearing (calmness), not skill, is the sign of a matured samurai. A samurai therefore should neither be pompous nor arrogant.’
Good luck!
Ranjan
Subject: NotesNinjas? Can’t believe that site’s still there!! 
Subject: RE: NotesNinjas? Can’t believe that site’s still there!!
Yup - still running! The design ain’t great, but we set it up to help the designer community… I like your site tho’!
Bye for now
R