We recently had an internal discussion about the refactoring of links works when a document is renamed or moved. Currently, it is by design that the refactored links are always saved as a minor version.
I understand that this approach makes sense because changing a document should always come with a well-documented history. However, we have usecases in our wiki where we would like to not have any new version created. For example, the management handbook and quality strategy of our company are documents in our wiki. We use workflows to manage changes in these documents. The change history is audited by external auditors. If these documents link to other documents in the wiki, they have new minor versions created whenever the linked document is moved or renamed and the last editor will change. Long story short, the audited documents will have unnecessary entries in their changelog by users that should not have any points of contact with these documents.
Other wikis (like Confluence) do not have this problem because they use an ID to identity the page and when you move or rename a page, the pages containing links remain unchanged. Therefore, in our usecase, we do not consider the refactoring of a link to actually be a change of a document. It is a technical necessity, but it does not change the document from a business perspective.
XWiki does have the option to bypass the creation of new versions when saving a document by using the XWikiDocument.setMetaDataDirty(boolean) method. Could it be a possiblility to use this feature when refactoring documents for updating links? Maybe as a global or space setting or by adding a flag to the rename/move page?
PS: I know about auto redirects, but they also come with drawbacks.
We don’t have this feature and it’s not been developed because it’s anti-wiki. The base concept of a wiki is that when the content of a document changes, there needs to be a revision created, for auditability. Since links are part of the document content, changing them changes the content end thus the history.
The refactoring could make mistakes, or renaming the link to point to a doc in another space could have consequences (for ex if the new target space has different permissions, meaning that previous readers would end up with a link they cannot acces), or any other reason. You need to be able to reconstruct the whole history that led to the current document content. If you have holes in your history then you’ll never be able to figure what happened, you’ll think there was some bug, you won’t trust history anymore, etc.
So, it’s very important to have the full history.
Now, if you understand all this and you want to customize your wiki, I guess you could develop some alternative behavior but I don’t think we could offer that as an option as we would push users to shoot themselves in the foot. The only thing we provide is the ability to turn off versioning if you don’t need it/want it. But then, if you do, there’s no ambiguity at least and you can’t try to reconstruct what happened to a document. Saving without a revision is like black magic.
I know I’m not helping you much, sorry about that.
Don’t worry about that. The answer was kind off what I expected
From a technical standpoint, I completly agree with you that every change should be documented in the history. But I also understand the perspective of our users and their business view on things, especially when coming from a wiki system that has no need for this kind of refactoring. They just “don’t care” about the technical necessity of the refactoring, they just dont want any entries in a document history that did not change the “business content”.
I guess one possible solution would be to be able to “filter” the document history. So that the history still contains all changes of a document, but you could create some sort of view that only includes actual changes made from the editor that would impact the semantics of a document. That could also exclude any script runs that would for example update a macro parameter or something like that. But it would require you to mark every version of a document with some sort of flag that is passed when a document is saved.
This is what we do already by hiding “minor” edits by default. You don’t need to review those (they’ll contain typo fixes, technical changes, etc). Ofc this means that the users use minor and major revisions properly.
This is kind of already the case. All automated refactorings set a revision message, which can be filtered on.
