Wierd Lotusscript ACL handles
Have a look at this little puzzle, the code below simply prints the names of all the entries in the ACL of a database, but it doesn’t work unless you uncomment the commented lines
Sub Initialize
Dim db As New NotesDatabase("", "acltest1.nsf")
' Dim acl As NotesACL
Dim entry As NotesACLEntry
' Set acl = db.ACL
Set entry = db.acl.GetFirstEntry
While Not entry Is Nothing
Print entry.Name
Set entry=db.acl.GetNextEntry(entry)
Wend
End Sub
So accessing the ACL through db.acl.GetFirstEntry returns nothing, unless you have stored a handle to the ACL. The odd thing is you don’t have to access it via the stored handle, db.acl.GetFirstEntry magically starts working. Has anyone got a rational explaination for this?
November 18th, 2008 at 11:03 am
Why don’t you just use “acl.GetFirstentry” instead of db.acl.getfirstentry?
November 18th, 2008 at 11:06 am
well I can, and did, but the wierd thing is that db.acl.getfirstentry doesn’t work by itself, and even wierder it starts working if you have a handle to db.acl that you don’t even have to use . . .
November 18th, 2008 at 11:30 am
It is most probably because inside the loop db.acl object is trashed by the garbage collector. You initiate a new db.acl object everytime the loop executes. However, when you explicitly set an object, it is retained until you delete it.
This is the most logical explanation that comes to mind.
November 18th, 2008 at 11:43 am
it isn’t to do with the loop, if the lines are commented out it never enters the loop, the first db.acl.getfirstentry returns nothing.
In fact, to simplify things further, this returns true, false:
Dim db As New NotesDatabase(”", “acltest1.nsf”)
Dim entry As NotesACLEntry
Set entry= db.ACL.GetFirstEntry
Print entry Is Nothing
Print db.ACL.GetFirstEntry Is Nothing
and if you swap the last lines it returns false,true so it isn’t the order of querying them.
November 18th, 2008 at 11:49 am
This is not limited to ACLs, I’ve seen it happen with references to databases as well.
My guess has always been that these objects are much like the session object, exposed as objects that we create but actually just wrappers onto other elements in the C code which are or are not initialised based on factors over which we have not control.
In the end my response is always “Ah LotusScript, we love you for your inconsistencies”
November 18th, 2008 at 12:27 pm
What you describe is quite logical. As the NotesACL class is Contained by NotesDatabase Class.
The return value of the ACL property of the NotesDatabase class is of type NotesACL. So you have to define a class first with a datatype of it so it can be used afterwards. Hope you understand what i mean (i do
)
For instance if you create your own class. And you want to get use of that class than you have to define it first also. This is exactly the same.
November 18th, 2008 at 12:47 pm
Hi Sjaak, it is normally fine to use the extended class syntax to drill right into things, you can do mad looking things like this
Print db.GetView("default").getfirstdocument.getfirstitem("form").values(0)if you want with nothing more than a handle to a database. You don’t need to put all the interim objects into declared variables if you don’t want to.November 18th, 2008 at 3:32 pm
I have seen this, too, in other places. I don’t recall where offhand, but I know that the extended syntax does not work consistently. I have gotten into the habit of declaring variables for every piece of an extended call instead of using the extended syntax. It just works better. I’ll join Matt: “Ah LotusScript, we love you for your inconsistencies”.
November 18th, 2008 at 3:37 pm
I think I am at best “just good friends” with LotusScript now.
November 18th, 2008 at 3:56 pm
Consider submitting a PMR
November 18th, 2008 at 4:36 pm
I can’t. I am a business partner not a customer. I could do a PBR in the partner forum I suppose. This isn’t something I am expecting will ever get fixed, unless perhaps someone can reproduce it in Xpages or Portal.
November 18th, 2008 at 4:47 pm
Just submitted a quick PBR. First time I have been in the forum since June.
November 19th, 2008 at 2:00 pm
Business partners may also log PMR’s. If you dig deep (:-D) on the Partnerworld website yo will find a link to submit PMR’s for IBM products.
So you are entitled to log PMR’s as a Busines Partner.
November 23rd, 2008 at 4:33 am
I don’t have a single lick of inside information, but, just by looking. the property .acl on notesdatabase is generating a new acl object (not a new ACL, but, the way of reading it). When you store a copy of the acl object in a field, it knows that it already has one, so, it does not generate a new one. When you do back to back db.acl.xxx its generating a new ACL object each time and getnextentry has not context because the. I’m sure that I’ve made some of those c++ types cringe at my explanation, but, thats my 2 cents.
December 6th, 2008 at 1:40 am
I’ve seen something very similar with the ACLManagement script library in the Mail8 template. I have an open PMR with IBM to help take a look at it, but here’s the details where you can see the same problem raising it’s head. (Basically on the Mail8 template you cannot delegate access to the mail file unless you are explicitly listed on the ACL as opposed to being a member of a group on the ACL. Use the R7 template with nearly identical code and it works..)
Brief Description:
===============
When trying to add a calendar delegate to a mail file, you get a LotusScript error
Steps to reproduce:
=================
Add yourself to someone else’s mail file ACL only as a member of a Group that has ACL editor rights (i.e. so you are not explicitly listed) such as Manager or Designer and attempt to delegate rights to someone else. You will get the error when you click OK to the Preferences pop up to save and close your changes and the ACL will not be modified or the Calendar Profile updated
If however you add yourself explicitly to the ACL as a Person that has ACL editor rights you can now successfully delegate with changes showing in the ACL and Calendar Profile.
Detail Analysis:
=============
If you repeat the same steps on the same client but instead work with mail files using the R7 template, then delegation succeeds whether you are listed directly in the ACL as a Person or only as a member of a Group.
The error message indicates the problem is at line 32 in the Actions > Tools > Preferences code but that’s because of the error handling. The exact error is:
Object Variable not set
On Module: CLICK
On Line: 32
On Method CLICK
However if you comment out the error handler in the Actions > Tools > Preference Code you can trace it back to the function IsNameInACL in the ACLManagement script library. It references Me.ACL.GetEntry(ACLName)
Set Me.aclentry = Me.acl.getentry(ACLName)
This code in the IsNameInACL function is not called if the user is explicitly listed in the ACL. The Me reference however would need to be set to the Database to be able to access the ACL entry. Instead the Me reference is pointing to the Database owner (type is DATABASEACLMANAGER) as far as I can see. Therefore Me..ACL.ACLEntry is an invalid property, this raises the error when returned to Preferences Action routine.
The only code difference that I’ve been able to find is in the ACLManagement script library in the Private Function SetDefaultAccess. The partial screenshot below shows the differences in the code (three lines starting at line 319 in the ACLManagement library under Declarations).
I did test changing the ACLManagement script library in R8 to be the same as in R7 but it still raises the same error in the same place. The ACLManagement library does reference the Common script library so my guess is that the ‘bad code’ is in there but just showing up during run time in the ACLManagement one. However doing a differential between the Common scripts would throw up a lot of changes I imagine.
The R8 template design is from StdR8Mail 8.01 (01/23/08) and the R7 is StdR7Mail 7.0.2 (07/24/06)