Prevent UI-Freeze in case of Endpoint-Failure

[fholzing]

Currently, the class CreateFromExperimentMenuItem Enables/Disables the MenuItem "Upload Runs from Experiment". To do so, it has some logic attached to the OnActiveViewChanged-Event and checks certain aspects of the content of the currently active view, such as if it is null or locked or the user has the required privileges.

A certain flaw emerges during a server outage, which may result in a UI-freeze until a timeout occurs.

[fholzing]

r16024: Made the permissions-check async and restructured the logic for short-circuit evaluation.

[fholzing]

r16025: Removed workaround.

[abeham]

I checked some other menu items and I think none of the other service-related menu items perform a check for privilege. Not even the other menu items in the OKB namespace. I think it's a nice way to check the permission and disable options the user doesn't have. But if it causes problems, then we can also get rid of it.

I see two options:

1. Just remove the privilege check altogether (consistent with everything else)
2. Implement a privilege check for all service-related menu items in a way that you have done

Do you know what happens when the service is badly accessible and I switch between some views several times. Will there be multiple calls to the service being queued or executed concurrently?

[swagner]

Replying to abeham:

I checked some other menu items and I think none of the other service-related menu items perform a check for privilege. Not even the other menu items in the OKB namespace. I think it's a nice way to check the permission and disable options the user doesn't have. But if it causes problems, then we can also get rid of it.

I see two options:

1. Just remove the privilege check altogether (consistent with everything else)
2. Implement a privilege check for all service-related menu items in a way that you have done

Do you know what happens when the service is badly accessible and I switch between some views several times. Will there be multiple calls to the service being queued or executed concurrently?

I would prefer not to check user permissions every time, when the active view is changed. Therefore, my recommendation is option 1. I want to rethink identity and rights management in general, when we think about necessary improvements for Hive.

[fholzing]

Replying to abeham:

I checked some other menu items and I think none of the other service-related menu items perform a check for privilege. Not even the other menu items in the OKB namespace. I think it's a nice way to check the permission and disable options the user doesn't have. But if it causes problems, then we can also get rid of it.

I see two options:

1. Just remove the privilege check altogether (consistent with everything else)
2. Implement a privilege check for all service-related menu items in a way that you have done

Do you know what happens when the service is badly accessible and I switch between some views several times. Will there be multiple calls to the service being queued or executed concurrently?

Just checked the behaviour: they will be executed concurrently, at least down to the ClientBase-Level. For each individual call a new ClientBase will be instantiated, therefore each ClientBase should have an unique ChannelFactory. A channel itself will handle requests in a sequential way. If they would share a common ChannelFactory, the TimeOut of one minute should terminate all requests. Also, the result is cached, so no new concurrent calls should happen after the first call returns.

[fholzing]

r16032: Removed permission check

[abeham]

In r16032 we have two GUI updates instead of one. Not that it matters, but I prefer it this way.

r16033: reduced to what it was before, but without privilege check

[mkommend]

r16049: Merged r16024, r16025, r16032, r16033 into stable.