Change Tracking Color Indicators not saved

[menelic]

The change tracking colors on one of the production instances of oC that I m running are displayed while the document is open, but are not saved and are not visible when reopening the Document in ownCloud. Text changes themselves (additions, deletions, reformatting) are saved, but not the author colors. This behaviour can be observed with uploaded documents as well as with documents created in the app. This bug defeats the purpose of collaborative editing, for which reason I d be very grateful for a fix. I m running this instance on shared hosting with All-Inkl.com.

oC Instance was installed as 6.0a, update to 6.0.1 did not solve the issue.

[VicDeo]

when saving to odt is done there is no reference to oc users any more It is just an odt file with a new content

[menelic]

Thanks for the quick reply - I think this is a misunderstanding. I know that the odt is plain, but I m referring to saving and opening from within OwnCloud, where the change-tracking author colors should remain visible after reopening the document (though they change between logins, which is why myself and others have requested persistent colors here #112 and here #186 ). I have edited the issue to clarify that I am talking about saving and opening the document within owncloud.

[menelic]

I just discovered the same bug in another oC 6.0.1 instance on another host. Are you really saying that the color markings are no longer saved between editing sessions? That would be killing one of the core features needed for collaboration, knowing who wrote what when? #112 was just fixed, but for that fix to be beneficial, surely the colors would have to persist from log in to log in.

[VicDeo]

If I got it correct.

1. a user has an odt document
2. he opens document, makes changes. Changes are NOT written to odt
3. he closes document. Changes are synced to odt
4. he opens another document with the same name from the point of content.

For multiple users usecase this is true when all users close document It works and always worked this way.

[VicDeo]

I expect some analogies with etherpad now. But Etherpad is NOT an odt editor. ;)

[menelic]

not quite - the changes in the text are saved, but the colors that indicate the authors are not. I will not refer to EtherPad, just to your demos in which I thought I had seen Colors indicating edits when I was the only person who was logged in.

In your list above, you lost me at 4. It's not another document with the same name - unless you are referring to the versioning system. I thought that precisely this versioning system was used to track changes in the Documents app.

All I m asking is why the colors that indicate edits (with time stamps on hover, no less!) are not saved between edits. Are you saying that the colors indicating edits are only visible while editing and not persistent between edits? That would mean I cannot use the Documents app to track collaborative changes, unless everyone is working in absolute real time. I am aware that the app does not implement the entire WEBODF spec, but based on their demo and the oC demo I did indeed expect persistence of authorship tracking in the app. I am aware that this is not saved in the odt file and not present on download, but I expected this to be a layer provided by the app with the help of the versioning system. Where is my mistake?

[VicDeo]

because changes are stored in db for the specific content if you have a document with a letter 'd' and you entered 'emo' changes are NOT in document yet. It still has 'd'. If you download it you won't have new content, only 'd'. But you close it and have a document with 'demo' inside. Session is closed, changes are synced.

Now you have a document with 'demo' inside. Otherwise when you reopen it you will have 'demo'+'emo' = 'demoemo'... etc

[VicDeo]

and don't forget that the same document may be edited locally by another user and uploaded with a sync client while it's still being changed via web interface by other users. So changes are marked for a static snapshot of this document. As soon as all users leave session, snapshot is disposed.

[menelic]

I do understand that. But if you are able to indicate changes with different author colors within a session, its precisely because of the existence of said databases and the versioning system that this should be possible between sessions as well - even if the static snapshot is disposed. I know I m not supposed to bring up EtherPad because WebODF uses a different file format, but the similarity is in the ways in which documents are displayed (and in the case of EtherPad even reassembled when opened) based on versioning data about changes committed to the file. If the oC Documents app is about collaboration and aspires to be a replacement for google docs and the like, surely it should at least be a feature worth aspiring to? Because I could achieve that effect even now if only I find a way of leaving that document open for the entire time of the collaboration. So why not have a collaboration mode? In some use cases, this would even be more important than local sync, which could be circumvented for such files, eg by adding conflicted version, collaborative version or somesuch to the filename.

If that is a no-go for useability reasons, which I could understand, then why not have a collaborative editing mode in which the static snapshot is never disposed and from which the document can only be downloaded once the collaborative editing mode has been switched off?

[menelic]

I remember now that another reason why I am expecting that feature is because @karlitschek made an explicit comparison with etherpad when he announced oC Documents, probably also in an interview on the Linux Action Show, but surely on his own blog, in a text that was syndicated on owncloud.com and elsewhere:

"We didn't introduce any new server requirements here. Just take ownCloud and put it into your web server document root and you have your own collaborative editing server. This is far easier to install and run than for example Etherpad."

http://blog.karlitschek.de/2013/10/welcome-owncloud-documents.html

[karlitschek]

@menelic Just to clarify. I didn't want to say in my blog post that etherpad and ownCloud documents are 100% the same. :-) There are good things and bad things in both approaches. But for a normal user ownCloud Documents should do the same as etherpad and even more like Rich Text, offline file syncing and so on.

[menelic]

@VicDeo @karlitschek tanks for the clarifications, I understand it much better now. I ll turn this into a feature request then: It would be great if you could implement text background color by user. where the user color is simply used as background color for each authors text. If this could be switched on and off on a per-document basis, oC documents would surpass EtherPad, GoogleDocs, Hackpad and the like. In some use-cases, it would be better than any implementation of "Track Changes", since background colors are more format-agnostic. I ll open a ticket and reference it here.