How to don't change history version after attachment added

Help / Discuss
#1

Hello everyone.
I need help with such problem: after I add a new attachment like screenshot or just picture (creating manual), a history version changes with every attachment. So, after I save these changes, history version increases on couple versions (equal to number of the new attachment files). But I don’t need it. I make one editing with a couple of images.
XWiki version: 12.1
Hope you understand my explanation. Thanks in advance for your answers

#2

Right now, attaching an image creates a new revision.

What’s the issue?

Thanks

#3

Thank you for reply.
Could I turn off this behavior? Because when I create a long document with a big amount of attachments it’s not convenient to see in History version “37” instead of “2”.

#4

No. You can turn off history but it’s all or nothing.

Why is that not “convenient” or a problem? (I’m curious to understand the need/problem).

In any case there’s nothing that can be done. You could provide a patch (pull request) to be able to change the behavior, you could sponsor the feature or you could simply create a jira issue and wait for someone interested in implementing it.

BTW, it wouldn’t be that easy to do: probably something providing a custom UI to be able to upload several files in a temporary location on the server before attaching them one by one to the page and doing a single save.

Related existing issues:

#5

Actually both the browser and the upload action API support handling several files at the same time but some reason the current upload UI generate a different HTTP call for each attachment.

#6

You mean the current server code? Because the UI is not ours when you drag and drop files onto the browser upload button.

#7

No I don’t mean the server code since the problem is the fact that several HTTP requests are produced instead of one. When you click on “Browse…” the browser let you select several files (because of the “multiple” attribute) but then whatever javascript which react to the selection to directly send the files to the server create a separated HTTP request for each file instead of a single one with all of them.

#9

ok so your point is that this issue should be easy to fix by modifying the javascript since we already have an upload action supporting several attachments and doing a single save, right?

#10

Now I’m not sure that we always want that. It can be convenient to have one revision for each file since that allows, for example, to rollback one without rollbacking all of them.

#11

Actually, it’s not a big problem, just not logical view in the History section. After this big amount of versions appears, I should start to delete versions that consists only “Uploaded new attachment …” for convenient using history.
Thanks a lot for your answers!