NeuShield Data Sentinel adds entries to Explorer context menus on protected folders and files within these folders. They don't appear in DO context menus. Windows menu-items are generally shown. On folders it has a submenu (Revert Changes / Commit Changes), on files just one entry (Revisions).
I have brought the issue to the attention of NeuShield support, but it may as well be something I could solve on the DO-side. Any ideas? Could I put sth like a shellext-dll to the menu myself?
If you run Notepad.exe and then use File > Open and right-click things in there, do the menu items appear then? Or do they only appear in menus shown by File Explorer itself?
Which versions of Windows and Opus are you using?
In the open dialog: they appear on folders in the treeview on the left, but not on files and folders on the right. It's Win 10 and DO 12.27
If it doesn't appear on things on the right, that suggests their shell extension is filtering where/when its items are displayed. It's something they would need to change (or explain).
Thanks, I forwarded that to them... 
Follow-up on this: they think it may rather be resolved by DO side. They would welcome sorting it out with you directly to see what can be done. As a workaround I can got to Explorer if I need to roll back a file to an earlier revision, but as DO is replacing E. as far as possible, I would prefer to have it accessible from DO directly when needed...
If their menu items don't show up in Notepad's File Open dialog (on the right hand side) then there's something wrong (or intentional) in their code which is preventing their items from appearing. We can't fix that, and I don't know why they'd think we could when we don't know what their code is filtering on or why, and when we can't change their code.
If we ask their shell extension if it wants to add any items for a given file or folder and it says "no" then we can't force it to do anything different.
They're presumably filtering by process name and/or certain CMF_* flags for IContextMenu::QueryContextMenu which aren't (and shouldn't be) set on the file display items (in both Opus and the standard File Open dialogs).
I can only guess, though, because only they know what their code is doing, unless I start trying to disassemble it, which is too time consuming, and would probably still end up in the same place: they need to change their code so it doesn't filter out their menu items in more places than it should, assuming they don't have a reason for the filtering. (Maybe they do have a reason, in which case they just need to explain that to you so it makes sense.)
Since the problem doesn't just affect Opus, and means their menus don't work properly in standard File Open dialogs, I don't understand why they would tell you that we can fix it.