Hi!
I’m developing a XProtect Smart Client plugin which, amongst other things, has a WorkSpacePlugin as a part of it.
I would like to make the workspace visible (or not) based on the state of a configuration item set in the XProtect Management Client - this enabling/disabling only has to take place when the XProtect Smart Client starts up, not change dynamically during the execution.
The configuration item is part of the plugin configuration (available through the XProtect Managemet Client via an item under the ‘MIP Plugins’ branch at the bottom of the configuration tree). The configuration item I’ve added to enable/disable the workspace works, and persists correctly.
My difficulty is that in order to access the configuration, it seems that the plugin needs to already be up and part of the visible layout before I have the information required to drill down to access the configuration item I need. By this time it’s too late - the workspace is already visible, which is what I was trying to prevent in the first place.
I feel like I must be missing something pretty obvious, but I can’t figure out what it is.
Really, what I would like to do is be able to access the configuration item in scope of the ‘top level’ PluginDefinition class. That way I could prevent the WorkSpacePlugin (and associated ViewItemPlugin) from ever being instantiated, and/or being added to the lists of WorkSpacePlugins and ViewItemPlugins in the first place.
Do you have any suggestions as to a best practice way to approach this sort of problem, or does one of the code samples address this in some way?
Thanks!
In your xxDefinition. Init() you should make a decision to add the workspace plugin or not.
You can here read the configuration (GetItemConfiguration or GetItemConfigurations) already before an Item Manager is in play and a workspace plugin loads.
Alternatively you treat this as a permissions issue and then you can implement ..
--
VideoOS.Platform.Util.SecurityAccess Class Reference
This class assists in maintaining security access for Items and validating what Items a user can access. The plug-in must be sure to register and unregister the Items that is under access control, e.g. has a SecurityAccess defined. This could be done in the ItemManager’s ValidateAndSave method ItemManager.ValidateAndSaveUserControl with a call to SecurityAccess.RegisterItem(item) and in the ItemManager.DeleteItem with a call to SecurityAccess.UnregisterItem(item).
The configuration of the actual access for each item is performed via standard Administration UI - no plugin development is required here.
Checking for application level security access must be done entirely by the plug-in, where relevant. SecurityAccess.CheckPermission is called for getting valid action for the Plug-in.
Checking for access to Items should be done in the ItemManager for maintenance actions, e.g. create/delete/view, but could be used other places if specific actions are defined.
--
Thanks Bo!
Apologies for my delayed reply - your answer took me back to my initial approach which I’d discarded after not having any success with it. It turned out that there was an issue with the way my configuration was being persisted which cascaded on to a larger issue, and once I realised this I was able to fix it all up.
Cheers! You can close this issue out as resolved.