-
I’ve search here for access control issues related to XPages, but found nothing. I even searched “help”. I can find nothing related to how XPages handle access controls. I would expect it to use the underlying form level access, but that is apparently not happening. Instead it appears to be using Roles only, and ignoring Groups, names, or any other aspect of the database ACL, where the Notes client pays attention to Groups, names, and other ACL configuration beyond the Roles.
-
I say this because the exact same user may edit documents in Notes, but may not edit them on the web using XPages, even though the Form is set to allow all readers access, the Reader and Author fields contains the user’s name explicitly and via a Group, but neither Reader nor Author contain a Role the user has. These documents have never contained a Role for this class of user and it has always worked in Notes.
-
Just searched the web. The XPages Blog says there is an “acl” setting under “data” for the XPage. Okay. Since this is empty, it defaults to Role-based access? That’s not what Matt says:
"So documents can still have readers and authors fields as normal and that security is honoured in the XPages. All you need to do to store readers and authors fields is add them to your form as you always have done, and then when saving data with an XPage, set the data binding to do a computewithform, this will force any computed fields on the form to be calculated and stored on the document. "
This explicitly says it should work as I thought, since I have computeWithForm set for other reasons. But it does not in fact work that way.
- I can only conclude that I’m missing something. Could anyone point out what that may be?
Thanks for your time…
Subject: Could be the computewithform…
Hi David,
I also had issues with the ssjs events not firing when using computewithform combined with author access.
For me it turned out to be a computed field with a @GetDocField and no @IsError. The web user did not have access to the related document, so this field returned error.
If one computed formula returns @Error computewithform just fails, no error is displayed or logged and it seems like the save event did not occur.
I know it’s a long shot, but perhaps it’s a similar issue in your case.
Bas
Subject: Where is the document being created?
If you are creating in XPages than check your readers and authors fields to make sure the readers or authors flag was set. It should appear like the following for an authors field:
The readers will just say read access.
Remember, the form access (on the form property) just sets the reader/author when a document is created with the form. I doubt that works on XPages. You have to create the field on the form and set the computewithform to onsave or both. I have found that computed fields don’t work this way and you have to put code in the postsavedocument event on the XPage to set the authors flag (isAuthors set to true.)
So, check your field settings first and make sure the fields are being set properly.
Howard
Subject: Thanks Howard, but I have checked the access fields…
-
The user in question is Dave Threetrain, who is also in the EE CATS EE-20 Group. In Notes, this suffices to give him edit access per the Authors field, since the default level for all users is Author. In XPages this does not seem to work.
-
computeWithForm is currently set to BOTH, because I had so many issues getting document data to appear correctly in LotusScript Agents, or when set by LotusScript Agents. Setting this to BOTH cleared most of that up.
-
The documents are created by LotusScript via import from a web service. This code was written years ago, and since it works it hasn’t been changed for web-enabling. The XPages only manipulate documents, they don’t create any.
Thanks for your time…
Subject: Ach. This is server-side events not firing … again…
- A brain cell fired and I manually entered the URL the SSJS event action should be building. Document edits fine as you please. I’ve been continually plagued with server-side events not firing, but never in this particular place before.
At least it’s a relief to know access controls work as excpected!
Subject: Actually this IS related to access as well…
-
When the user has a Role that’s in the Authors field, the server-side event fires. When the user does NOT have a Role that’s in the Authors field, the server-side event does NOT fire. I just verified this by giving Dave Threetrain the [CorrOffice] Role, so he has a Role from the Authors field, and now the server-side event fires fine as you please. Take that Role out … nothing.
-
This must be a bug. But it is a known bug? Since BP can’t search for SPRs, could an IBMer do that and tell me if this is known? If not I’ll put in a PMR on it. If there’s an SPR for it already I don’t see the point, but what is the workaround? It’s not tenable to add a Role for each and every Group, and some people get picked willy-nilly from the NAB and aren’t in a Group, which is why the name and the Group appear in the Authors field.
Thanks for your time…
Subject: Might be better to open a PMR
So that you have someone spend time researching it and a customer report can be put against the SPR if needed.
To check for ACL related issues you can use DEBUG_SERVERACL=2
It is quite verbose so I would recommend only using while testing.
Subject: I did open a PMR…
Apparently it is inappropriate to relate experience with support, and I can’t delete a post, so I edited it instead.