Bug 93713 - "Unprotect Cells" missing from Table Menu and Table Toolbar (comment 6)
Summary: "Unprotect Cells" missing from Table Menu and Table Toolbar (comment 6)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All All
: high minor
Assignee: Yousuf Philips (jay) (retired)
URL:
Whiteboard: target:5.0.2
Keywords:
: 83011 94494 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-08-27 13:18 UTC by Charles
Modified: 2015-09-27 05:23 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Charles 2015-08-27 13:18:05 UTC
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...
Comment 1 Charles 2015-08-27 13:24:35 UTC
One other user on the users list confirmed the bug on Linux Mint, so changed the OS to All...
Comment 2 Cor Nouws 2015-08-27 14:08:40 UTC
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
Comment 3 Charles 2015-08-27 14:21:21 UTC
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...
Comment 4 Charles 2015-08-27 14:23:38 UTC
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.
Comment 5 Charles 2015-08-27 14:51:24 UTC
Updated to reflect that this bug is still present in the new 5.0.1.2 release just announced today.
Comment 6 Maxim Monastirsky 2015-08-27 15:07:32 UTC
@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.
Comment 7 Cor Nouws 2015-08-27 17:06:20 UTC
it's enough to have one issue. Marking this as duplicate.

*** This bug has been marked as a duplicate of bug 93714 ***
Comment 8 Charles 2015-08-28 11:21:32 UTC
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.
Comment 9 Charles 2015-08-28 11:36:37 UTC
@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.
Comment 10 Maxim Monastirsky 2015-08-28 12:04:36 UTC
(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.
Comment 11 Charles 2015-08-28 13:13:13 UTC
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.
Comment 12 Charles 2015-08-28 13:17:37 UTC
Thanks for confirming @Maxim...

Bug 93746 opened...
Comment 13 V Stuart Foote 2015-08-28 23:34:55 UTC
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.
Comment 14 V Stuart Foote 2015-08-28 23:35:07 UTC
*** Bug 93714 has been marked as a duplicate of this bug. ***
Comment 15 V Stuart Foote 2015-08-28 23:38:04 UTC
s/"Unprotect protect"/"Unprotect cells"/
Comment 16 Heiko Tietze 2015-08-28 23:52:55 UTC
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.
Comment 17 V Stuart Foote 2015-08-29 00:07:34 UTC
@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.
Comment 18 Heiko Tietze 2015-08-29 00:41:37 UTC
(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.
Comment 19 V Stuart Foote 2015-08-29 14:31:27 UTC
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?
Comment 20 Yousuf Philips (jay) (retired) 2015-08-29 23:02:04 UTC
(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.
Comment 21 Cor Nouws 2015-08-31 22:24:07 UTC
(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
Comment 22 Cor Nouws 2015-08-31 22:24:57 UTC
(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  :)
Comment 23 Yousuf Philips (jay) (retired) 2015-09-01 07:51:43 UTC
Patch is in - https://gerrit.libreoffice.org/18222
Comment 24 Commit Notification 2015-09-01 08:35:38 UTC
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.
Comment 25 Charles 2015-09-02 12:55:34 UTC
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.
Comment 26 Maxim Monastirsky 2015-09-02 15:31:13 UTC
(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
Comment 27 Charles 2015-09-02 16:45:41 UTC
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...
Comment 28 Maxim Monastirsky 2015-09-02 17:22:28 UTC
(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.
Comment 29 Charles 2015-09-02 17:27:15 UTC
? Code from AOO is most certainly usable in Libreoffice...

Unless - did the code never make it properly into OOO/AOO?
Comment 30 Maxim Monastirsky 2015-09-02 17:42:42 UTC
(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.
Comment 31 Mark Bourne 2015-09-09 18:35:49 UTC
*** Bug 83011 has been marked as a duplicate of this bug. ***
Comment 32 V Stuart Foote 2015-09-27 05:23:05 UTC
*** Bug 94494 has been marked as a duplicate of this bug. ***