On pc Debian x86-64 with master sources updated today, I could reproduce this.

I confirm bug under Win8.1 x64 with LibO 5.0.3.1

I tested it with older LibO releases too and it never worked.
The same behaviour is present in OOo 3.3.0 and AOO 4.1.0 as well.

so issue is "inherited from OOo"

Created attachment 119935 [details]
edit links dialog screenshot

Code pointer:
cui/source/dialogs/linkdlg.cxx line 222
    222         if( FILEOBJECT & pLink->GetObjType() )
    223         {
    224             m_pRbAutomatic->Disable();
    225             m_pRbManual->Check();
    226             m_pRbManual->Disable();
    227             if( OBJECT_CLIENT_GRF == pLink->GetObjType() )
    228                 pLinkNm = 0, pFilter = &sLink;
    229         }
    230         else
    231         {
    232             m_pRbAutomatic->Enable();
    233             m_pRbManual->Enable();
See http://opengrok.libreoffice.org/xref/core/cui/source/dialogs/linkdlg.cxx#222
Some testing show we go into the if because:
1) #define FILEOBJECT ( OBJECT_CLIENT_FILE & ~OBJECT_CLIENT_SO )
2) pLink->GetObjType() returns 0x92 (which corresponds to OBJECT_CLIENT_OLE)

Several possibilities:
1) Should FILEOBJECT macro be changed to:
#define FILEOBJECT ( OBJECT_CLIENT_FILE & ~OBJECT_CLIENT_SO & ~OBJECT_CLIENT_OLE) ?

2) Should pLink be initialized as OBJECT_CLIENT_SO and not OBJECT_CLIENT_OLE ?

3) These kind of links shouldn't be "updateable" indeed and so there's no bug

4) Other?

Here are the different types:
     50 #ifndef OBJECT_DDE_EXTERN
     51 #define OBJECT_INTERN       0x00
     52 //#define   OBJECT_SO_EXTERN    0x01
     53 #define OBJECT_DDE_EXTERN   0x02
     54 #endif
     55
     56 #define OBJECT_CLIENT_SO              0x80 // a Link
     57 #define OBJECT_CLIENT_DDE           0x81
     58 //#define   OBJECT_CLIENT_OLE         0x82 // a Ole-Link
     59 //#define   OBJECT_CLIENT_OLE_CACHE   0x83 // a Ole-Link with SvEmbeddedObject
     60 #define OBJECT_CLIENT_FILE          0x90
     61 #define OBJECT_CLIENT_GRF           0x91
     62 #define OBJECT_CLIENT_OLE           0x92 // embedded link

See http://opengrok.libreoffice.org/xref/core/include/sfx2/lnkbase.hxx#50

Michael: any thoughts or any idea who may help here?

@Julien Nabet

Thankyou for giving the site of the code!

It is really strange! On the one side a dialog box comes all the time for asking to update for objects which shouldnt be as here described updateable if I see so? (bug 95302)

On the other side: why to give this option if always a FILE-OBJECT is eliminated? I mean is there anyother object which has a Link which is no file and in conclusion not updateable? This sounds really silly to me.

I experimented a little and enabled the radio buttons artificially. What came out that its really PSEUDO. When you come back to the dialog when keeping the file open it doesnt forget if a Link should be updateable automatically or manual. But if you reload the file after you saved it, it forget those preferences. It seems, there is no implementation behind it?

Bug 95302 made the conclusion to only implement general settings. This bug here could come to the conclusion to either
(1) delete those radio-options described in this bug
(2) or that if in the Links-dialog are made different settings, it can overwrite the general Impress-settings
(3) Eliminating Automatic or Manual per file and summarize it for all files. Because should there be 10 dialog files at the beginning so ask each file yes or no? If in general there is manual, then you still can go to Links and click 'update' for each selected file

Which speaks for (1) eleminating the radios - is that it is most easy because bug 95302 can create the more easy solution.

If for every file it need to be stored wether to be updated or not it seems that the file standard has to be changed, does it? This would affect the compatibility to Microsoft Office and other office programs much more? 

For example if I first edit in Impress. Then update something in Powerpoint. Would the update automatic/manual Information would go away? Cause then this is a minus to make the dialog links in the automatic/manual-update function really work...?

How the community thinks about it? Only general settings or also individual settings by this dialog box Links? Making those settings in Links finally work or to eliminate them because general settings are the more ergonomic solution?

duplicate of https://bugs.documentfoundation.org/show_bug.cgi?id=48294 ?

*** This bug has been marked as a duplicate of bug 48294 ***