This is not necessarily a pressing issue, as there is a workaround, but it has piqued my curiosity about how QGIS manages hyperlinks through its 'Action' functionality. Please feel free to correct my if I get some terminology wrong here, I'm not strong on the IT side of things.
I have a shapefile with an attribute field containing a full filepath to a server location (\\IP address\folder\folder\file.format). This is to prevent issues with trying to access these files from different machines where the drives may be mapped differently, as opposed to directly to the drive, for example (C:\etc.).
This has worked perfectly well both in ArcMap and QGIS 3.0, setting up the hyperlink and clicking the feature behaves as expected, the file opens in the correct program. Note that as the full filepath is stored in the attribute the Action script just has the field [%Hyperlink%] and nothing else.
However, using QGIS 2.18.20- which is what most people who are accessing this data are using, and this is why it is important- once the action has been set up, using the action tool on a feature elicits no response at all, not even an error message. Is this something to do with mapping the file location to the server directly? If so, how and why do the two versions of QGIS treat this differently?
Edit: Upon implementation of the recommendation by eurojam, using a direct python script to access the file, I have at least got an error message. It seems that possibly there is some issue with how the filepath data is being stored that is not reflected in the attribute? the error message reads:
<
An error occurred during execution of following code:
import os
os.startfile('\172.17.50.18\vsdcid117_vol3_archive_srrc\Assets\IMG_US_Roads_March_2018\9C2B20A700335B4_1_P\9C2B20A700335B4_1_P.gps', 'open')
Traceback (most recent call last): File "", line 2, in WindowsError: [Error 2] The system cannot find the file specified: '\172.17.50.18\x0bsdcid117_vol3_archive_srrc\Assets\IMG_US_Roads_March_2018\9C2B20A700335B4_1_P\9C2B20A700335B4_1_P.gps' >
The filepath in the first section is how it should read, and this is what shows in the attribute table, however the second iteration, which it appears is the one that Python is attempting to work with, has some interesting formatting variants- the double backslash, and 'x0bsdcid117' where it should read 'vsdcid117'. I used the ArcMap field calculator to build the filepath string, and used the double backslash as an escape character so that the string would end up reading as it does once the filepath string had been concatenated with the file name. Does this have something to do with it?