A client is using an URL type attribute to point to documents. (FQN notation)
With IE the documents can be opened.
However with Google chrome this isn't working.
Anyone seen this before and knows how to solve ?
Is there any error message that you see ?
No, only blank screen.
Any pop-up blocker ?
Have you checked the settings in Chrome ?
Is this for everyone using Chrome or only a few ?
there's no pop-up blocker. Also checked settings in Chrome. Can't see anything related.
I suppose this is for everyone using Chrome.
And.. does it work ok when trying with IE or Firefox?
What is the chrome version? As far as I know, that should work.
yes, IE and FF work ok.
There are some issues identified with google chrome -
Version 30.0.1599.66 m Issues
The following CA Clarity PPM issues occur for users who are using this particular version
of Chrome (Version 30.0.1599.66 m):
■ The Recent Pages (History) drop-down that lets you navigate back to previously viewed pages does not work.
■ Export to Excel and Export to PowerPoint do not work at the portlet level.
■ Export to Excel does not work on a list page.
These issues do not appear in other browsers and have been found only in this version of Chrome.
It's with the latest version of Chrome (40.0.2214.111)
you should check with support.. but according with Release Notes (compatibility matrix) from Clarity 13.3
Supported Chrome versions:
Google Chrome 31.x.x. or higher release(*)
Note(*): .... Chrome releases may be supported with minimal testing after being released. Google Chrome versions 29, 30 and 31 have known issues with CA Clarity PPM and it is recommended to use version 32 or higher.
So, most likely Chrome 40 did not exist when Clarity 13.x version was released.
check if support if there is a known issue..but it will be a known issue from Chrome most likely. Have you tried with an older supported and tested version( ie: 32)
A support issue will be created.
However, on Firefox there's a different behavior. When clicking on the go button of the url field, it opens a window but puts http://localhost/niku/nu in front of the actual content of the field.
Seems that the 'go' definition is interpreted differently in IE, FF or Chrome
If you go to http://yourserver/niku/wsdl/Query and click on any of the query names listed, you should see some XML displayed (the xsd file for that query).
Almost at the very bottom will be a <soap:address location="..." />
Is everything on that URL up to the /niku part matching the same URL that you had in the browser for connecting to Clarity, or does it happen to say localhost there too?
If it says localhost, you will need to revise your HTTP/HTTPS/Scheduler Entry URL settings in the CSA and update them to the correct values, then (ideally) restart the app service and check again to see if the localhost (and rest of the URLs in the wsdl xsd file and Go buttons) has been replaced with the correct values.
In any of these queries, there's a setting :
The scheduler url is set to http://win-0I3L910BPFC/niku/nu
Based on this, then it is your HTTP/HTTPS Entry URL fields that aren't populated for the app service (either they contain localhost or are left blank).
Here for example is how they are set on one of our sandboxes:
Without this, links in notifications, links in Export to Excel, the addresses in the WSDL XSD's, and potentially elsewhere that Clarity has to 'present forward' to a client the address to be used when connecting back to it (like Xcelsius portlets) can have the wrong address and not work as expected. I suppose in your case you should use/try this value in your HTTP Entry URL field for the app services: http://win-0I3L910BPFC:80
Nick, i agree.
But even if i change that, in Firefox, the behavior is different.
If i click the go button i'm getting something like this : http://win-0i3l910bpfc/niku/\\WIN-0I3L910BPFC\C$\temp\import.txt
In IE only the \\WIN-0I3L910BPFC\C$\temp\import.txt is shown resulting in an open document.
In Chrome, only a blank tab is shown.
Strictly speaking, those aren't URLs but UNC paths for Windows shares, and trying to use them in URLs will likely result in confusion or different results from one browser to the next.
You can't really use the URL field to pull or reference things from \\server\share\path\file.ext
That isn't a fault of any browser or setup, it's just not a valid way to link to the files by using a URL attribute. You could TRY with a valid file:///.. syntax but even then I'm not sure that's valid for trying to pull data to a workstation from a network share (especially hidden shares like C$ which typically require users to have administrator privileges to the machine in question).
Retrieving data ...