our RCP application consists of many different perspectives reflecting different business use cases and processes. These perspectives are authorized such that the current user may navigate only to some of these perspectives depending on his rights.
The workbench state is stored during shutdown. This state also holds the currently active perspective. But if after user 'A' has worked in perspective 'x' another user 'B' (not authorized for perspective 'x' ) starts the application he will see perspective 'x' because the workbench has restored its former state and with it the last active perspective.
Until now we didn't find a way to hook into the restore process to check if the last perspective is authorized for the current user.
Do you have any idea how to work around this problem?
Torsten Beuck wrote:
> Hi,
>
> our RCP application consists of many different perspectives reflecting
> different business use cases and processes. These perspectives are
> authorized such that the current user may navigate only to some of these
> perspectives depending on his rights.
>
> The workbench state is stored during shutdown. This state also holds the
> currently active perspective. But if after user 'A' has worked in
> perspective 'x' another user 'B' (not authorized for perspective 'x' )
> starts the application he will see perspective 'x' because the workbench
> has restored its former state and with it the last active perspective.
>
> Until now we didn't find a way to hook into the restore process to check
> if the last perspective is authorized for the current user.
>
> Do you have any idea how to work around this problem?
>
> - Torsten
You can disable the saving by WorkbenchConfigurer.setSaveAndRestore(false)
I have a similar problem with Perspectives needing filtering based on
user authorization, but also needing the ability to store there own
modified perspectives. I worked out the first with a parallel set of
Perspective-SecurityFunction (and same for views and action sets)
references using an extension point.
For the restore problem, I recommend relocating the user home directory
to the OS users hoem directory, assuming a different user is also a
different OS user. You can do this with the -data directive in
eclipse.ini. I use -data @user.home/bhs-client/ so the workspace stuff
like logs and prefs is stored there.
Works for me...
Maarten Meijer
eclipse trainer & consultant
Torsten Beuck schreef:
> Do you have any idea how to work around this problem?
>
> - Torsten
Paul Webster Messages: 6813 Registered: July 2009 Location: Ottawa
Senior Member
Having the workspace per-user as suggested earlier will help with most cases, except constantly running the application in the same user.
The other places you can do cleanup (like close an open perspective) before the system is fully up is org.eclipse.ui.application.WorkbenchWindowAdvisor.postWindow Open() or org.eclipse.ui.application.WorkbenchAdvisor.postStartup()