I’d like to discuss and gather ideas for solving the problem of integrating Change Request with the realtime edition.
So to give a quick recap of the problem: Change Request currently injects in the various editors (WYSIWYG editor / object editor / class editor) a button “Save as change request” which allows user to create or add the proposed changes in a change request. But recently some work has been done to bundle a realtime editor in XWiki Standard and to have it as the default editor. The problem is that this new editor prevents using change request: first, from a pure UI PoV, the toolbar changed preventing to inject the “Save as change request” button, but then, more importantly, the design itself of the realtime editor prevents using CR as it saves the changes automatically.
I asked @mflorea his opinion on the chat about that, and he answered the following to me:
I see two options:
decide from the start if you want to create a change request or edit directly; basically, instead of “Save as Change Request” we’d have “Edit as Change Request” (or something like that);
vs. add support for draft editing in XWiki and change the edit action to always edit / create a draft; realtime / autosave will update the draft; at the end you’ll have two options: either merge the draft directly in the original document or create a Change Request; Confluence is using drafts BTW.
it has its own drawbacks, as I pointed on the forum
Note that for the first option “Edit as Change request”, it’s something we already almost have technically speaking: it’s the edit option that is available if a user doesn’t have Edit right, but has the right to create a change request.
Problem with that option is that users would have to select it instead of their usual editor (it could be considered as another editor actually), meaning that they cannot chose while they’re performing editions.
Now as mentioned, a proper implementation of drafts wouldn’t be trivial, but I’m still wondering if on the long run we wouldn’t need the concept in XS?
Even if the first options seems the simplest to implement I have the feeling that the second one is the best long term since it would allow having several users create a CR together. It also seems nicer from a usability POV.
So basically you make changes and that creates a draft when editing (if your browser crashes and can still get back your changes) and when you save you decide if the draft is converted to a proper change or a CR. I guess it could work either by asking when closing the edit window or by checking a “Save the changes as a CR or add to an existing CR” checkbox in the UI when editing (a single user from the RT session would enough to decide to save as a CR). Or something like that. Is this what @mflorea had in mind with the second option?
More or less. The way Confluence does it, AFAIR, is:
each page can have a single draft associated (to be double-checked but from my tests with two accounts, both users were editing the same draft)
when you enter edit mode if there’s no draft, one is created, otherwise the existing one is being edited
other users can join editing the draft
auto-save updates the draft
you can leave edit mode and edit again later, i.e. continue editing the draft
when you think the draft is in a complete state you have the action to update the original page (i.e. merge your changes), and the draft is deleted (I assume)
Here, the main goal of the draft, as I see it, is to prevent the viewers from seeing intermediary changes auto-saved from the realtime editing session. This single draft design can’t work for us (as is) because we have multiple ways of editing a page. You can’t edit in realtime using both Wiki and WYSIWYG editors at the same time. Moreover, if you have two WYSIWYG editors installed, you can’t use both in the same realtime editing session. So in our case we need to have a draft per edit mode / editor, which complicates things a bit.
This single draft per edit mode doesn’t help with Change Request. The problem just moved from the original document to the single draft. For Change Request we may need to support multiple drafts per edit mode, but this complicates the UI.
The problem is that realtime needs auto-save, and auto-save can’t work with Change Request unless you know from the start that you’re going to create a Change Request. If you start editing without planning to create a Change Request, the auto-save will update:
either the original page (current state)
or the associated single draft that may be edited by other users (Confluence like)
or a user-level draft, but then if each user gets automatically their own draft when entering edit mode then you don’t have realtime editing anymore
So I’m afraid auto-save forces you to choose whether to start a change request when entering edit mode.
Or once a RT session is active, we disallow editing with another editor.
I don’t understand this part. If RT does auto saves in a draft, and if CR plugs at the same level as the Publish button (ie there’d be two buttons: Publish and Save as CR), then I don’t see the problem. Publish saves the draft into a real doc and Save as CR creates a new real doc (a CR one).
By the time you get to chose whether to publish or create a CR, another user editing the same draft might publish your changes:
you start editing, auto-save kicks in and your changes are saved to the draft
another user enters edit mode and makes some changes that are saved on the same draft
This means:
if you create a CR it won’t include only your changes
the other user doesn’t know that you plan to create a CR and thus can publish your changes; or, in other words, you and the other user may have different plans:
you’re making a bigger change that requires some review so you’d like to create a CR
the other user wants to fix a typo or to make a small change that they are very sure of, so they want to publish directly
To add to that, we also need to take permissions into account: A user who wants to create a change request might not have edit right on the page, while another user might have edit right. Can they edit together in the realtime editor? And could it then happen that the edits of the user without edit right are directly saved by the user with edit right?
ok thanks, I understand now. So the issue isn’t technical, it’s about the intent.
Now this is true for any page edit, whether it’s a CR or not. I may be editing a page to fix a typo and then someone jumps in an makes bigger modifications, drowning my simple change.
So we could this by deciding when clicking Edit that the edit is about a CR (Edit as CR) but we could also do this more generically by having an option to Edit alone and when you want to create a CR you’d use that. Another alternative would be to allow the first editor to indicate somewhere in the edit UI his intent, by filling a free-form text (or click on predefined texts for well-known cases). Thus anyone joining would see the intent indicated.
I think it could still be interesting to allow RT when creating a CR, so that you can co-create a CR. Now, I don’t know if CR supports this ATM (several authors) but it could be an improvement I guess if it doesn’t.
+1 for using drafts as the target of what is being edited in a real time session.
In my opinion, not only does this facilitate integrations with other features (e.g. being able to collaboratively create a Change Request) but more importantly, it is more security conscious.
In an enterprise setting, having content go live instantly without the chance to reflect on whom should be able to see the new content will always be considered risky IMO.
In a similar vein, I’m not a massive fan of everyone being able to join the live session (I believe this is the intent…). It would be better if someone who is part of the edit was required to accept participation of others.
This would solve the issue of CR mentioned above and you wouldn’t need to “Edit as CR”. You could just edit and if someone wants to join but you’re not planning to work with someone on your upcoming CR you’d refuse (would be nice to have a text message to explain why you’re refusing).