Mimic a User's Portal Experience
A
Arnt Richard Rørvik
This function would make it easier to see the user's view of the portal, no matter what OS or version. This could be implemented for instance as follows:
From Admin-console, select Portal (or Mimic OS/version) with choice of OS:
Default (i.e. same OS as that of the admin user)
macOS (and version)
Windows (and version/variant)
etc.
When in Portal, show Admin that Portal is in OS simulation mode, with OS/version/variant (header of browser/top of portal windows)
And of course instruct the portal that this is the OS running so that the admin can see what apps are available, try to launch downloads, run on servers etc.
(Ideally) block and inform the Admin if trying to launch apps from non-compliant OSes.
Return to Admin to exit this mode
A. R. Rørvik
Mark, thanks for your kind remarks.
Certainly - yes impersonating is indeed a word covering the most of it. There may be several dimensions, such as os type, geo location, machine ownership, on site, on domain etc. and these could be selected in a simple form before going from admin to portal. Seeing is believing; for those operating helpdesk or checking the look-and-feel that would be essential. It would make testing easier for e.g. Javascript code in Description that provides different info to different factors (os/geo/owners/off-onsite, off-ondomain etc=. And generally, browsing and seeing how things might appear for a Linux - or Mac, iPad-user, such as starting downloads, that might have different sources depending on different distribution methods that may or may not be equal between the different factors.
M
Mark West
Thinks is something we've raised before albeit not in this form.
The overall goal is to assist our service desk in helping users access applications and explaining/understanding why they might not be able to given the users context.
Each time our SD have to escalate a "user can't see application X" ticket that impact the user experience.
Currently AA offers no simple way for a service desk analyst to understand why an app might or might not be available to a user.
An alternative solution would be a "read-only admin" role and a page that allows the SD analyst to type a username then pick the app, os, geo location, machine ownership (i.e. all the factors that affect availability) and for AA to spit out an answer as to if this apps is available (and just as importantly why it isn't).
-Mark
M
Mark West
Further new version of AA does an even worse job than the old one of assisting the user in this.
This one of our apps on my home machine (it requires an onsite device due to access to a license manager).
Spencer Vale
Mark West: For apps that appear as unavailable, as you have seen we have the "Why unavailable" feature. All of the information that was present in 2.11 and earlier was there solely to help determine why the app was unavailable, but the main feedback that we got is that for many people it was too much information, and too hard to decipher. The new why unavailable feature aims to provide a simple reason - for example your OS is not supported, or the app is not available in your region. This uses the same information that was available previously - so if it can't determine why an app is unavailable, it should be likely that the previous data wouldn't have been sufficient either.
However, there may be some cases where that's not true, which we would see as a defect. In this case, if there's something you could determine from the old information, but not from the new feature, please send us a support request outlining how the app is set up so we can see what we can do. These may be affected by whether you've validated or not, what device you're on, etc, so if you can provide any of that information (and for example whether a better message is displayed after validating), that would be really helpful.
Finally, we know there are some scenarios where the old data isn't sufficient but could still result in an unavailable app, and we hope to bridge some of those gaps in a future version.
M
Mark West
Spencer Vale: I'm 99% sure it'll be bug AA-477 which came from ticket #1648 we reported some 4 years ago.
Essentially our DM's don't restrict app but the provision does. AA when displaying the apps takes this into account but the display of availability info doesn't. Our hope (and expectation) was that the move to an API driven product would see this logic unified into a single API rather than duplicate code working differently.
-Mark
Spencer Vale
Mark West: Thanks. I'll take a look into it.
Spencer Vale
Merged in a post:
Applications restrictions not showing in new UI
M
Michael Coxon
Posted in the old CR Forums: https://support.appsanywhere.com/hc/en-us/community/posts/7222266793885-applications-restrictions-not-showing-in-new-UI
In the old UI there was a way to view applications restrictions by showing more info and there was restrictions tab, now that only seems to appear if the application is actually restricted to you. Likes of our support teams found it useful to see that info to help fault find why a user may not see an app, is there a way to have that info shown even if you do have access to it.