We have a ton of Writer Templates with Tables in them, that have certain cells protected (containing formulas). Users sometimes unprotect (right-click on cell > Cell > Unprotect) to delete the formula and manually enter numbers. I just discovered - after updating a lot of our users - that apparently this is broken in the first 5.x release. There simply is no 'Cell' context menu option, and nothing in any of the Menus to allow me to Protect/Unprotect the cell...
One other user on the users list confirmed the bug on Linux Mint, so changed the OS to All...
Hi Charles, Thanks for your report here! The items is removed from the context menu. Via Table > Protect cells, you can protect them... However, I see now that Table > Protect cells is disabled in ... protected cells :\ So that means you cannot unprotect. OK for you to change this report in a bug for that? Cheers - Cor
Hi Cor, Thanks for the fast response... (In reply to Cor Nouws from comment #2) > The items is removed from the context menu. Via Table > Protect cells, you > can protect them... Can you point me to a/the issue where the rationale for removing this very useful function from the context menu was discussed? We use that feature from the context menu all the time. I'd be fine with it being changed to Table > [Un}Protect Cell, but in my opinion this ability really should be in the context menu. > However, I see now that Table > Protect cells is disabled in ... protected > cells :\ > > So that means you cannot unprotect. > > OK for you to change this report in a bug for that? I will do so now. Thanks for confirming...
Changed summary to reflect that [Un]Protect Cell was removed from the context menu, but that the new way will not allow me to Unprotect a Protected cell.
Updated to reflect that this bug is still present in the new 5.0.1.2 release just announced today.
@Charles: As a workaround you can add it yourself to any menu or toolbar. You can find it at the "Add commands" dialog under the "Table" category. (And the 'Version' field should list the earliest affected version, so I reverted your change there.) @Jay: Any chance of adding this command to the Table menu in 5-0? I think we should consider this despite the UI freeze, because users won't find how to unprotect cells.
it's enough to have one issue. Marking this as duplicate. *** This bug has been marked as a duplicate of bug 93714 ***
Re-opening, because bug 93714 is only a feature enhancement request to bring back the context menu choices for protecting/unprotecting cells that was apparently intentionally removed from the context menu. This bug is the report of the actual bug that there is now presently no way to unprotect a cell in a Writer Table once you have protected it.
@Maxim Thank you! Now at least I won't have to revert the 10 or so people I've already upgraded... But I just noticed another cosmetic bug... can you confirm before I go open another bug report? 1. Add a new Writer Table with 5+ columns... 2. Click inside a cell 3. Protect the cell Note that the cursor jumps to an adjacent cell. Unprotecting a cell does not cause the cursor to jump to another cell.
(In reply to Charles from comment #9) > 2. Click inside a cell > 3. Protect the cell > > Note that the cursor jumps to an adjacent cell. Confirmed.
Changing Summary to reflect that this is just a problem of missing menu entries. Once the 'Unprotect Cells' option is added to the Table Menu and/or Toolbar, it works as expected.
Thanks for confirming @Maxim... Bug 93746 opened...
Moving over to UX-advise This clean-up of toolbars, and reduction of context menu clutter, is intended to make the UI simpler for the beginner user--aka for Benjamin. An experienced user--aka Eve, would know to customize their toolbars, and that not every feature has to be present in the context menu to be readily accessible. So, it is and was correct to remove from context menu per Design/UX-Advise actions, but believe like Maxim that if we are going to have a Table -> "Protect cells" menu button, we should also have a Table -> "Unprotect protect" present by default.
*** Bug 93714 has been marked as a duplicate of this bug. ***
s/"Unprotect protect"/"Unprotect cells"/
Is it possible to have this option as a toggle item? The check mark would indicate if the protection is active, what is missing as well right now (except from the fact that some items are disabled), and offer the opportunity to unset aka unprotect.
@Heiko, * Not sure that a selected/non-selected toggle button status for "Protect Cells" alone is going to be effective UI/UX. Protect/Unprotect are not really linked in that the Table menu entry is contextual to text cursor position in the table. To see behavior, customize the Table menu and add the "Unprotect Cells" button back to the menu, then protect a couple of table cells. Note that the Protect/Unprotect buttons will toggle available or not depending on the status of the cell as you move the text cursor. And of course, the same behavior when you add the "Protect Cells/Unprotect Cells" labeled buttons to the Table toolbar. The cleanest UI would be to keep the two distinct stateful buttons and add the Unprotect Cells button to the Table menu.
(In reply to V Stuart Foote from comment #17) > The cleanest UI would be to keep the two distinct stateful buttons and add > the Unprotect Cells button to the Table menu. I was afraid of this answer. If it's not a property but a function we cannot have a simple solution out of the box. Although this would be the most cleanest UI - and I'd still take refactoring into consideration therefore.
So, in master Writer's reworked Table menu already has the "Unprotect Cells" with Jay's rework for bug 91781, so that will be in 5.1 (and folks should can compare with a test drive of master). For a 5.0.2 build, we don't need that entire patch cherry picked, rather just insert the .uno:UnsetCellsReadOnly command adjacent to .uno:Protect in sw/uiconfig/swriter/menubar/menubar.xml to resolve this. @Jay, are you set up for a a 5.0 build?
(In reply to Maxim Monastirsky from comment #6) > @Charles: As a workaround you can add it yourself to any menu or toolbar. > You can find it at the "Add commands" dialog under the "Table" category. > (And the 'Version' field should list the earliest affected version, so I > reverted your change there.) @Charles: Even easier, both protect and unprotect buttons are in the table toolbar, but hidden by default, so right-click on the toolbar and click 'Customize Toolbar' to enable them. > @Jay: Any chance of adding this command to the Table menu in 5-0? I think we > should consider this despite the UI freeze, because users won't find how to > unprotect cells. (In reply to V Stuart Foote from comment #19) > @Jay, are you set up for a a 5.0 build? @Maxim, @Stuart: Yes adding it to the table menu, similar to 5.1, would likely be the simplest thing to do for 5.0.
(In reply to V Stuart Foote from comment #13) > Moving over to UX-advise > An experienced user--aka Eve, would know to customize their toolbars, and > that not every feature has to be present in the context menu to be readily > accessible. I object to be forced to use the mouse. (Anyway, working with toolbars in combination with the key board is a pita) Access in either context menu or main menu is fine. Thanks
(In reply to Yousuf (Jay) Philips from comment #20) > > (In reply to V Stuart Foote from comment #19) > > @Jay, are you set up for a a 5.0 build? > > @Maxim, @Stuart: Yes adding it to the table menu, similar to 5.1, would > likely be the simplest thing to do for 5.0. Ah yes - would appreciate that :)
Patch is in - https://gerrit.libreoffice.org/18222
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9e1f02096297725761552074123eb3cecab49e83&h=libreoffice-5-0 tdf#93713 Add 'Unprotect Cells' to Table menu It will be available in 5.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thought I'd already responded to this... (In reply to V Stuart Foote from comment #13) > Moving over to UX-advise > > This clean-up of toolbars, and reduction of context menu clutter, is > intended to make the UI simpler for the beginner user--aka for Benjamin. That is all well and good, but not at the expense of hobbling your existing users/power users. > An experienced user--aka Eve, would know to customize their toolbars, and > that not every feature has to be present in the context menu to be readily > accessible. Depends on your definition of 'readily'. As of now, the ability to protect/unprotect cells is much less readily available for me, as now, instead of 'right-click>click', I have to click on the cell, move the mouse to find the desired menu (or toolbar button), then click again. Much less user friendly. > So, it is and was correct to remove from context menu per Design/UX-Advise > actions, That is totally a matter of opinion, and is not one I'm in agreement with. > but believe like Maxim that if we are going to have a Table -> > "Protect cells" menu button, we should also have a Table -> "Unprotect > protect" present by default. In my opinion, you should not have removed long standing context menu items that your existing and long time users are now very familiar with, without first providing a way to edit the context menus so that you would not totally alienate your existing user base, as they would have a simple way of putting them back. In fact, personally, I see bug 93837 (Allow customization of the Context Menus) as something that should have been done a long time ago. That said - I think the fact that there wasn't already a bug open to add this ability speaks well of the choices so far for how the Context Menus have been designed and maintained by the UI team.
(In reply to Charles from comment #25) > In fact, personally, I see bug 93837 (Allow customization of the Context > Menus) as something that should have been done a long time ago. > > That said - I think the fact that there wasn't already a bug open to add > this ability speaks well of the choices so far for how the Context Menus > have been designed and maintained by the UI team. Actually there *is* a bug for it since 2002: https://bz.apache.org/ooo/show_bug.cgi?id=7449
Interesting - and it looks like they actually made some (no idea how much) progress in 2010/2011... So, any coder willing to look at this and consider picking it up, maybe there is some code already done that could be used. I like that they were using .xml files, those would be easy to duplicate for other users...
(In reply to Charles from comment #27) > Interesting - and it looks like they actually made some (no idea how much) > progress in 2010/2011... Indeed. > So, any coder willing to look at this and consider picking it up, maybe > there is some code already done that could be used. The code exists, but unfortunately its license is not suitable for inclusion in LO.
? Code from AOO is most certainly usable in Libreoffice... Unless - did the code never make it properly into OOO/AOO?
(In reply to Charles from comment #29) > ? Code from AOO is most certainly usable in Libreoffice... This code is not part of AOO. It was a branch in OOo, and AFAIK wasn't part of the Oracle code dump to Apache.
*** Bug 83011 has been marked as a duplicate of this bug. ***
*** Bug 94494 has been marked as a duplicate of this bug. ***