<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - Allow to open linked documents when trying to edit protected sections" href="https://bugs.documentfoundation.org/show_bug.cgi?id=144350#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - Allow to open linked documents when trying to edit protected sections" href="https://bugs.documentfoundation.org/show_bug.cgi?id=144350">bug 144350</a> from <a class="email" href="mailto:mikekaganski@hotmail.com" title="Mike Kaganski <mikekaganski@hotmail.com>"> Mike Kaganski</a> <pre>(In reply to Heiko Tietze from <a href="show_bug.cgi?id=144350#c7">comment #7</a>) > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>