Created attachment 174849 [details] Error message Spin-off from bug 143482 (with some better demonstrations): Master documents contain sections to the sub-documents. Editing those protected sections results in an error message "Write-protected content cannot be changed.". It would be useful to provide an interaction on this dialog to open the linked document. In normal documents I cannot select a protected section (Navigator > Go to jumps to the following paragraph), so this message is probably not relevant there. Otherwise I could imagine to hide the "Open" button if the section doesn't contain a linked document. Mike, does this make sense?
The dialog itself is very basic, and it doesn't know which kind of read-only content triggered it. It would fail the same way when you have protected tables, or ToCs, or other fields, or whatever. Personally I would think that *first* we need to improve the information in the dialog, so that it reports *which* read-only content it is: we have some reports (don't have a ref at hand) about people being confused by the message, not seeing why it pops up in the first place. Only after that it could be possible to suggest improvements in conditional interaction.
At least for the master documents the message itself is clear but title and subtitle are redundant. Surely we can improve this - and have to for other places. But usability-wise it's bad to tell a user "what you want to do is not possible". Either block the interaction or provide alternative workflows (open document in this case). So yes, we should improve the thing from ground.
(In reply to Heiko Tietze from comment #2) > At least for the master documents the message itself is clear No. You just see it in one single place. But in the same master document, you may see it in many other places - basically anywhere where it's possible in normal documents.
Created attachment 175229 [details] A master document filled with ordinary write-protected content In the attachment: 1. There is a ToC that by default protects its content. 2. A field. The document has field protection enabled. So selecting the field and trying to overwrite will fail. 3. A table with protected cells. 4. A protected section. All these are in the master document itself, not in some linked document. Trying to modify those will give the same dialog. And what's more, selecting all (Ctrl+A) and pressing Del will give the same dialog, too - so what would be the intended workflow (what should the dialog contain) in *this* case?
(In reply to Mike Kaganski from comment #4) > what should the dialog contain) in *this* case? If the context doesn't apply, hide the control. So if the confirmation box starts from a write-protected field, we don't show the action button to load the document. If the action is temporarily not available, in this case when the selection includes different sources ion ctrl+A, we disable it. Of course, we have to consider whether the effort justifies the benefit.
(In reply to Heiko Tietze from comment #5) > If the context doesn't apply, hide the control. Which is exactly what I mentioned: you need to provide the information from the action into the dialog. And note the current logic: now the action checks if there is *any* locked content affected by *any* operation; often it doesn't need to analyze everything, and may break when encountered *the first* locked element affected. What would need to be done is to analyze *everything* (to build the correct context for the interaction), which would introduce this complexity into all actions that could potentially give this warning; the analysis before the interaction would take longer (for bigger selections). It might make sense, though - but I don't think it's an easy change at all.
It's acceptable to ignore the multi-selection use case. How about the interaction on/off in case of one object?
(In reply to Heiko Tietze from comment #7) > It's acceptable to ignore the multi-selection use case. How about the > interaction on/off in case of one object? LOL. You are talking about attempts to edit *some content inside a "section"* (the linked document). You should realize that it would be *typical* for users to have complex selection inside that content - trying to just type, or selecting a single object in the inner document is just a special case. It is *not* appropriate to try to resolve this special case and pretend you are handling the problem. Second: you try to invert the logic: instead of passing the context from the place where the problem was detected, you want to make the *dialog* "smart", trying to figure why was it started. So the logic would be: 1. Some code, having all the required information to know what happened, finds out that the operation is not permitted; it runs a generic dialog. 2. The dialog opens, and starts analyzing what is the situation, trying to figure who run it and why; doubling the complexity ("reverse-engineering" the problem), and asking for new bugs because of impossibility to do that correctly in all the numerous cases.
In a nutshell, Mike would resolve the issue as WONTFIX. And his opinion a senior developer is of high value to me. Do you agree, L Duperval?
(In reply to Heiko Tietze from comment #9) > In a nutshell, Mike would resolve the issue as WONTFIX. And in turn, I would suggest to focus on L Duperval's original request to add an "open the document" context menu, shown just next to "edit section" menu when clicking anywhere inside the nested document.
(In reply to Heiko Tietze from comment #9) > In a nutshell, Mike would resolve the issue as WONTFIX. And his opinion a > senior developer is of high value to me. Do you agree, L Duperval? Yes that's fine. I hadn't thought of all the complexities surrounding that request.