Hope this helps clarify for those out there as it has been a rabbit hole. a user Shares or Copies a link via email, in another document, inside of SP, outside of SP to a document that gets moved?) - run a scan with a third party product to find Broken Links and automatically fix or report them to their owners to fix up. So what am I going to do about link integrity (e.g.
This has been escalated to MSFT to fix as the whole purpose of Document IDs is to find it wherever it may roams using Enterprise Search and I am certainly not entertaining the thought of telling users they can't use the 'Move' button on the ribbon (as it is really a copy) and need to navigate to the Content & Structure tool in the backend to Move the file so it will retain its original DocID even if it did work. Note: I was advised that the only way you can move a document and retain its DocID is by using the Content and Structure interface - I have tried this and you cannot move or copy a file into itself or any of its branches.įinally, from a technical perspective it was explained to me that the Devs scripted the Move function by copying the Copy function with one extra step - it obviously deletes the original source document. If you move outside of this - the link breaks and a brand new DocID is generated. Documents only retain there Document ID when moved within the same library. Documents with Durable links will also break if moved outside of the Library. I think RD stopped support for its old API and thats why Genesis is not working anymore. Microsoft have got back to me and the answer is on both SP On-Prem and Online: It was told that the last thing working in Genesis was going to be RD links, but they would eventually fail because of the new RD API.
0 kommentar(er)
