PLC Connect Security Definitions not working (VB error in faceplate)
Hi, strange case here:
I have put parts of a new project (PLC connect) in the functional structure, where one operator should have restricted access (not allowed to operate faceplates).
On testing, we found that the operator with restricted access is allowed to operate the faceplate.
Existing objects in the same structure (not PLC connect) still works as intended - operator cannot operate them.
---Level with Security Definition
-----Old FS obj 1..
-----Old FS obj 2..
-----Old FS obj 3..
-----Old FS obj etc..
-----Our new FS object
Are there any other settings that should be set on PLC Connect specifically for this to work?
What I have seen is that when the operator in question opens one of the faceplates he's not supposed to be able to operate. When he closes this faceplate again, two messages in operator message list appears:
Write Failed: The Data Access Write Operation was rejected because the user has no permission to write to the item.
VB error: "Method '~' of object '~' failed" in OurTagname:OurFaceplatename :: UserControl_Hide
So it seems something is happening, but the actual hiding of the buttons fails? Comparing with the tags that the operator does not have access to, only the message about Write failed appears.
Thanks for any help you can give.
With VBPG you can add custom code that attempt to write regardless of what button is pushed or not pushed by the user. Does your VB code attempt to write on close?
Neither SoftPoint nor PLC Connect implement "permissions" as most other connects within System 800xA does; hence you can not set e.g. "Operate", "Configure", "Tune" etc. on a SoftPoint/PLCC property.
If the property is set as "Is Controllable" on the SoftPoint/PLCC type/instance writes may be attempted from SoftPoint/PLCC GUI (Object Dialog) but I doubt if this "Is Controllable" status propagate to the "IsWriteAccessGranted" subproperty of the OPC DA framework of 800xA?
In lack of implementation of permission, the default permission will be assumed by System 800xA which is "Operate*" (the asterisk '*' indicates the effect of default security). If you revoke "Operate" from a user, 800xA will not permit that user to write to anything using default security (unless a security is implemented and some other permission is set on property AND met by the user).
I also seem to recall a security permission problem with PLC and Softpoint objects when it comes to Objects and Descendants...
I suspect we might need to continue this as a regular support case; please consider reporting this to your regional ABB support center.
Stefan found the solution, I'll put it here for reference in case someone finds this question later.
The problem was that the child objects on the PLC objects (the "data accessing objects" that actually connect to different values in the OPC server) were not in the Functional Structure, only Control structure.
As we have out security definitions in the functional structure, they did not propagate down to the child objects that the faceplate buttons are connected to.
The only solution seems to be to put the child objects in the functional structure as well.
How to implement this on 400 tags with a total of 60000 child objects is another story.