Hiding User defined commands in VLF ONE Framework

[pravik]

Hi,

We have created user defined commands, and its mapped to commands allowed tab of VLF ONE framework. We would like to restrict user from accessing each command defined under certain criteria. We have identified a way to disable them, we would like to know how do we hide them programmatically so that users would not be shown with these tabs.

Command which we used to disable is as below:
#AVFRAMEWORKMANAGER.avChangeCommandState Objectname(#OBJNME) Commandname(#CMDNME) Enabled(False)

Thanks & Regards,
Priya

[pravik]

Hi All,

Can some one help us with ideas in order to achieve hiding of user defined commands.

Thanks & Regards,
Priya

[jyoung]

I don't know if you can hide them with the exception being the "Hide All Other Commands" http://docs.lansa.com/14/en/lansa048/in ... lf0319.htm

The VLF-ONE Quick Reference is good place to look for the available Objects and APIs and besides the avChangeCommandState it does not "look" like there is a way to do what you are wanting. http://docs.lansa.com/14/en/lansa048/in ... 8_6745.htm

However, you could likely work around it. We've had to do something similar with Filters when the out of the box functionality did not allow us to do something.

In this case, you could make one command handler and in that command use Tabs that act as your command handlers. In essence the only command would be a container for your tabs. This would give you to the option to show / hide YOUR tabs as you see fit. There are some side affects to this however; such as you cannot use avSwitch to switch to a different command, you have to handle it yourself in your container command.

Hope this helps,
Joe

[MarkD]

If you use the VLF authority model then you can allow or disallow access to a framework, applications, business objects and their associated command handlers. If a user is not authorized to use a command then it will not appear (in fact it does not even exist).

[MarkD]

You can also snap in you own authority model by supplying your own server side authorization logic - http://docs.lansa.com/14/en/lansa048/in ... 7_0070.htm

Your logic is run once at logon time and allows you to screen out any commands (or applications, etc) that the user is not authorized to use.

Since unauthorized command definitions (or applications, etc) are not sent out to the client they don't exist in the user's version of the framework.
This is considered to be a more solid authorization model than using client side logic to hide things.