Bug 74585 - UI RFE: Options for disabling/re-enabling/deleting/restoring AutoCorrect entries per user
Summary: UI RFE: Options for disabling/re-enabling/deleting/restoring AutoCorrect entr...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-05 19:55 UTC by dg1727
Modified: 2015-03-05 15:18 UTC (History)
2 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 dg1727 2014-02-05 19:55:56 UTC
On the Tools > AutoCorrect Options... > Replace tab, the available actions are New and Delete.  

There would preferably be Disable/Enable actions so that a user can disable an AutoCorrect entry only temporarily, then re-instate it without having to retype the Replace: and With: strings exactly the way they were.  

An example is if a user wants to refer to a list item that (s)he has previously written and types (C) ... this gets AutoCorrected to a copyright symbol ... the user may want to disable only this AutoCorrect entry for only that document.  AutoCorrect would stay enabled on that document (so "teh" still gets corrected to "the", for instance), and then the user could re-instate the (C) AutoCorrect for future documents without having to enter a copyright symbol into the With: box.  

Another example is if an AutoCorrect "Replace" string happens to be the same as a proper name or a tradename (or part of a multi-word one), maybe in a foreign language, or a source-code variable name or something, that the user wants to put into just that document.  

The UI should make it easy to see (either in the existing dialog or a subsidiary dialog) what Disabled entries exist so the user can [a] remember they've been disabled and [b] choose which ones to re-enable.  

I'm using LibreOffice 4.1.4.2.
Comment 1 Cor Nouws 2014-02-05 20:57:09 UTC
Hi dg,

(In reply to comment #0)
> An example is if a user wants to refer to a list item that (s)he has
> previously written and types (C) ... this gets AutoCorrected to a copyright
> symbol ... the user may want to disable only this AutoCorrect entry for only
> that document.  

Did you consider to use Ctrl+Z (undo)
IMO this works so easy, that I tend to set this as WorksForMe...

OK?

cheers,
Cor
Comment 2 dg1727 2014-02-05 22:52:04 UTC
A document that happens to have many instances of a word that is in the Replace list could make Ctrl+Z get annoying.  Also, Ctrl+Z might not be obvious to many users, since it connotes "undo the last thing *I* did," and the AutoCorrect wasn't done by the user.  

You can set this to WORKSFORME and if enough users in the future find this enhancement request and want the feature added, then the bug can be reopened.
Comment 3 QA Administrators 2014-09-03 21:33:02 UTC
Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.


Thank you for helping us make LibreOffice even better for everyone!


Warm Regards,
QA Team
Comment 4 Cor Nouws 2014-09-03 22:13:49 UTC
(In reply to comment #2)

> You can set this to WORKSFORME and if enough users in the future find this
> enhancement request and want the feature added, then the bug can be reopened.

Fair enough, dg. Especially since you ask for a per document solution..

(Sorry I did not respond earlier.)
Cor
Comment 5 dg1727 2014-11-30 03:20:50 UTC
I have some follow-ups:  


1.  I notice that the summary (title) of this bug had "per document" added.  I admit that my original feature description mentions "on that document" or "just that document" a couple of times, but I think a per-user implementation is what I was really thinking of.  I'm sure this would be easier to code than a per-document implementation.  

I think it's perfectly OK that in a per-user implementation, the user would have to remember to re-enable a particular AutoCorrect entry (affecting all documents being edited) when (s)he is done with a document that needed that entry disabled.  


2.  The existing options of "New" and "Delete" don't provide an obvious way to un-delete.  This seems like it is user-unfriendly enough to need improvement.  

My original idea, if taken literally, would have resulted in there being only options for Delete, Disable, Enable.  So there wouldn't have been any improvement regarding un-deleting.  (The user would have had to use the Reset button at the bottom of the dialog to un-delete "en masse.")  

I revise my suggestion to the following:  

a.  Make a distinction between AutoCorrect entries that are "factory default" and those that are added by the user.  This could be done by adding a list column like "Source" with values like "LibreOffice" or "User."  The 2 lists (LO & User) should be alphabetized together into one list, since there are so many entries that the user won't want to scroll through 2 separate lists to find what (s)he is looking for.  

I propose item (a) because many users, and especially their sysadmins or support people, would like an obvious way to restore configuration to the "factory" settings (and in many situations, this should be on a dialog-by-dialog basis, not just for the whole software suite).  Also, having the LO & User lists be distinct on disk would mean that the LO list can be auto-updated without affecting the User list.  This is already done with spelling dictionaries.  

b.  There would also be a list column for "Status" with possible values Enabled, Disabled, Deleted.  

c.  It would be preferable to allow the user to sort either alphabetically (as in the existing dialog) or by Source (to see just his/her own additions) or Status (to see what's been disabled or deleted).  

d.  If an entry is in the LO default list, its available action is Disable (or, if the entry is already disabled, Enable).  There would be no way to delete these entries.  

e.  As noted in item (1) above, any customizations made by the user (including changing the Status of an entry) are stored on a per-user basis, _not_ per-document.  

f.  If an entry was added by the user, Disable/Enable is still available; but there are also a Delete option, to erase entries that are simply mistakes, and a Restore option, to undelete.  Items that were deleted from the user list are restorable as long as the application is running (i.e., across multiple invocations/closings of the dialog).  When the application exits, deleted items are deleted permanently.  

g.  The Reset button brings up a dialog that says something like:  "This will re-enable all disabled AutoCorrect entries, and restore all user-supplied entries that have been deleted since {date & time when the application was started}.  Are you sure?" with buttons OK & Cancel.  


I have attempted to clarify the bug summary per my various points above.  

From my original comments, I repeat that it seems user-unfriendly to have to wipe out (for example) the AutoCorrect for (C) _permanently_ (or at the price of having to re-enter both the Replace & the With manually), or learn to press Ctrl-Z all the time, to disable (C) during only a day's worth of editing.  

I am setting this request to REOPENED, not because of that, but because there is no evident way to un-delete just a single entry that was deleted (apparently, all LibreOffice-supplied entries that were ever deleted are restored along with it), and no evident way at all to un-delete a user-supplied entry.  

Thanks for bearing with me on this.
Comment 6 Robinson Tryon (qubit) 2015-03-05 15:18:36 UTC
REOPENED isn't the correct status for this bug, as there wasn't ever a developer assigned or fix released.

Changing status back to previous state: RESOLVED WORKSFORME