Bug 137298 - Should only show Edit Fields dialog for date/time fields inserted from Docinformation tab and where appropriate show File - General - Properties - Description
Summary: Should only show Edit Fields dialog for date/time fields inserted from Docinf...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Fields File-Properties
  Show dependency treegraph
 
Reported: 2020-10-06 20:19 UTC by sdc.blanco
Modified: 2021-07-13 09:52 UTC (History)
5 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 sdc.blanco 2020-10-06 20:19:02 UTC
1. Ctrl-F2 (Insert - Fields - More Fields)- Docinformation tab
2. Insert any Type.
3. Double-click the inserted Field  (i.e., Edit Field) 

Actual result (generalized): 
Not possible to edit any field of any Type from Docinformation (except for changing Format of Time and Date fields).

Expected result: ???

Additional information:

1.  Maybe not supposed to be edited? In that case, Edit Field dialog should only be possible if a Time or Date field (to change format).

2.  Maybe some Fields should be editable.

3.  Hidden agenda:  If possible to edit Type "Created", Select "Author", then it would resolve bug 103212 and bug 117954

4. Tested with 7.1.0.0.alpha, but possibly "Inherited"
Comment 1 Dieter 2020-10-07 05:34:38 UTC
(In reply to sdc.blanco from comment #0)
> 3.  Hidden agenda:  If possible to edit Type "Created", Select "Author",
> then it would resolve bug 103212 and bug 117954

Sorry, but problem is not clear to me. I can insert field with type "created" and the date. I can edit that field and change to "Author"

I think, I need some more detailed steps.
Comment 2 sdc.blanco 2020-10-07 07:45:15 UTC
1.  Tools - Options - User Data, fill in First / Last Name, Apply.
2.  Ctrl-F2, Docinformation Tab.
3. Choose Type "Created" and Select "Author"
4. Press Insert
5. For the Inserted field (presumably the name you filled in in Step 1), double-click

Actual result:  Edit Fields dialog appears, but no possibility to edit the field.

Generalisation:  
1. Use File - Properties, fill in Subject, Title, Comments, Keywords.
2. Ctrl-F2 Documentation tab, insert the fields from Step 1.
3. Double-click on each of these fields.

Actual result: (same problem).  Edit Fields dialog appears, but nothing can be edited.

The problem:
Should one be able to edit the text fields?  
   If yes, then not possible at present. (bug?)
   If no, then why even show the Edit Fields dialog (bug? UI enhancement?)

Slight Exception:  For all the Date and Time fields, it is possible to change the Format, so meaningful to show Edit Dialog.

Retested with today's current master, running in Safe Mode (to avoid User Profile problems).
Comment 3 Dieter 2020-10-07 16:12:13 UTC
(In reply to sdc.blanco from comment #2)
> 1.  Tools - Options - User Data, fill in First / Last Name, Apply.
> 2.  Ctrl-F2, Docinformation Tab.
> 3. Choose Type "Created" and Select "Author"
> 4. Press Insert
> 5. For the Inserted field (presumably the name you filled in in Step 1),
> double-click

I can select "Time" and "Date" and also select formats for both. I can't change the Author, but that is of course nothing I would expect.
Comment 4 sdc.blanco 2020-10-07 16:30:31 UTC
(In reply to Dieter from comment #3)
> I can select "Time" and "Date" and also select formats for both.
As was reported. 
> change the Author, but that is of course nothing I would expect.
This applies to all non Date/Time fields.  Why offer an editing dialog, if editing is not possible?  Seeking a second opinion, needsUXEval
Comment 5 Dieter 2020-10-07 16:48:40 UTC
(In reply to sdc.blanco from comment #4)
> Why offer an editing dialog, if
> editing is not possible?  Seeking a second opinion, needsUXEval

I think this depends on understanding of "Edit": Field is "Created" and I can select between "Author", "Time" and "Date". So for me it is possible to edit the field.
Comment 6 sdc.blanco 2020-10-07 18:01:49 UTC
(In reply to Dieter from comment #5)
> I think this depends on understanding of "Edit": Field is "Created" and I
> can select between "Author", "Time" and "Date". So for me it is possible to
> edit the field.
Thanks for clarification.  I understand better now.  Two-part response.

Part I.

For Types:

  Comments
  Keywords
  Subject
  Revision Number
  Title

Double-clicking these inserted fields provide a dialog box with the title "Edit Fields". but nothing can be edited or changed.  Not a catastrophe, but why allow it at all?

Part II.

  Created
  Last printed
  Modified

I misunderstood that "Select" changes which value is shown for the "Created" type. 

If I had inserted Created - Author, I would not expect that Editing that field would mean that I could change it to Date or Time.  Rather I expected that I could edit the content of the field (like a variable). I would not think to use Edit Field to change Created (Type):Author (Select) to Created (Type):Time (Select).

In other words, with these cases, I interpreted the interface to mean that for each "Type", three different "Selections" are offered for editing (like with Variables)

I hope these examples show the need to:

(a) consider not offering the Edit Fields dialog for Part I cases, and for non-Date/Time fields in Part II

(b) consider whether the labels "Type" and "Select" are appropriate labels for DocInformation "Edit Fields" (I think they have been carried over from Variable fields, where those labels are meaningful).  If point (a) is implemented, then the dialog box would be closer to "Modify Format" -- because double-click would only allow editing on those fields where actual changes could be made.
Comment 7 Heiko Tietze 2020-10-09 07:53:43 UTC
You can edit keywords, for example, via File > Properties > Description. Double clicking a field in general should bring up the edit field dialog and not anything else but we could give access to the properties dialog from there. The "Edit" button seems to be well suited for this.
Comment 8 Cor Nouws 2020-10-14 11:15:33 UTC
the content of the docinformation fields is taken by the program from the document. So only editing for e.g. date formatting makes sense.
If so, this reads as notABug ?
Comment 9 sdc.blanco 2020-10-14 12:49:48 UTC
(In reply to Cor Nouws from comment #8)
> the content of the docinformation fields is taken by the program from the
> document. So only editing for e.g. date formatting makes sense.
> If so, this reads as notABug ?
There was not a "Inelegant Design" category available.
The issue is why show the Edit Fields dialog for 5 of the 8 Docinformation fields that cannot be edited in any way? As noted in Comment 7, there might be appropriate alternatives in some cases when double-clicking the field, and comment 6 suggests better labeling in the Edit Fields dialog, when it is shown for the appropriate cases.  Have changed bug summary.
Comment 10 Heiko Tietze 2020-10-15 07:44:54 UTC
We discussed the topic in the design meeting.

+ Document (Sender) reads data from Tools > Options and allows editing while DocInformation (Author) takes the values from File > Properties, which must not      change
+ don't show the "Edit" button at all?
 + maybe just hide until it's editable, which is apparently only for one type possible

=> AI: double check when Edit is enabled and decide whether to hide completely


sw/source/ui/fldui/fldedt.cxx Init() has

if (pCurField->GetTypeId() == SwFieldTypesEnum::ExtendedUser)
    m_xAddressBT->set_sensitive(true);
else
    m_xAddressBT->set_sensitive(false);

No idea what ExtendedUser exactly means.
Comment 11 Mike Kaganski 2020-10-15 09:33:50 UTC
Or maybe activate the "Edit" button (under the Type list in Edit Fields dialog), and let it open Document Properties?
Comment 12 S.Zosgornik 2020-10-15 11:46:43 UTC
I was checking the "Edit"-button for all the field categories and came to the conclusion that it is only active for the "Sender" category where it leads to Tools>Options>User Data.
IMO useless, since users usually only fill there file once.
Comment 13 Mike Kaganski 2020-10-15 11:54:58 UTC
(In reply to Sascha Z from comment #12)
> I was checking the "Edit"-button for all the field categories and came to
> the conclusion that it is only active for the "Sender" category where it
> leads to Tools>Options>User Data.

So this observation confirms, that using this button to go to the correct dialog for this information is the way to go.

> IMO useless, since users usually only fill there file once.

No. There are multiple questions here and there regarding modifications of that data on demand ... so it's OK to have that button, and then - to use it consistently, as suggested in comment 11.
Comment 14 S.Zosgornik 2020-10-16 13:07:28 UTC
(In reply to Mike Kaganski from comment #13)
> No. There are multiple questions here and there regarding modifications of
> that data on demand ... so it's OK to have that button, and then - to use it
> consistently, as suggested in comment 11.

Using the Edit button inside the author section to edit document properties was exactly what I suggest on the last UX-meeting. But this was rejected for the reasonable concept an (initial) author shouldn't be altered.

Do you know any other suggestions for using this very button?
Comment 15 Mike Kaganski 2020-10-16 13:16:46 UTC
(In reply to Sascha Z from comment #14)
> (In reply to Mike Kaganski from comment #13)
> > No. There are multiple questions here and there regarding modifications of
> > that data on demand ... so it's OK to have that button, and then - to use it
> > consistently, as suggested in comment 11.
> 
> Using the Edit button inside the author section to edit document properties
> was exactly what I suggest on the last UX-meeting. But this was rejected for
> the reasonable concept an (initial) author shouldn't be altered.

Is "author section" what is "Document" tab has, named "Author", with "Name" and "Initials" under "Select"? Then the UX meeting decision was wrong. Because the type "Author", amusingly, does not mean "author of the document" - the latter is under "Created" on DocInformation tab. The discussed "Author" type on "Document" tab is about ... current user, and modifying it at any time is fine. (But of course, the field name likely needs attention to become more correct.)

> Do you know any other suggestions for using this very button?

No; but I don't think we need more suggestions. Simply when any field uses some property available elsewhere, the Edit button *should* be used to open that place directly; that's how it was designed.
Comment 16 Mike Kaganski 2020-10-16 13:36:34 UTC
(In reply to Mike Kaganski from comment #15)

And if the Author from DocInformation is meant, then editing it is also an option. We have the UI for that - under File->Properties (General tab); just editing options are limited to clearing (resetting) the information. I believe it's still a valid thing to do.
Comment 17 Heiko Tietze 2020-10-20 12:02:51 UTC
Insert > Fields > More > DocInformation > Created is the same as Insert > Fields > Author (.uno:InsertAuthorField) and takes the value from Tools > Options > User Data when the document is being created. Changes to this option affects Insert > Fields > More > Document > Author but not the DocInformation.
File > Properties > General > Created use the inital values, which can be reset to the current options per Reset Properties. 

I still vote for keeping this workflow and dropping the Edit button since it is used for only one feature with not much benefit. => NAB
Comment 18 Mike Kaganski 2020-10-20 12:08:40 UTC
(In reply to Heiko Tietze from comment #17)

Keeping this button active, and enabling it to open relevant Properties dialog, has additional benefit of providing useful information to the user: clicking it, user can learn where does this information come from. It is self-documenting and educating.

I see *absolutely no* downsides in keeping it. Do we have a bug report like "I see this button (if it would work), and I feel paralyzed by its presence"?
Comment 19 Heiko Tietze 2020-10-20 12:15:27 UTC
(In reply to Mike Kaganski from comment #18)
> Keeping this button active, and enabling it to open relevant Properties...

Sure, but it will not _edit_ the properties (unless using Reset).
Comment 20 Mike Kaganski 2020-10-20 12:18:33 UTC
(In reply to Heiko Tietze from comment #19)
> Sure, but it will not _edit_ the properties (unless using Reset).

which *is* editing (limited) :-)

I suggest to only remove something if its removal itself has benefits over keeping, not because it's "not much harm".
Comment 21 S.Zosgornik 2020-10-20 15:57:01 UTC
(In reply to Mike Kaganski from comment #18)
> 
> Keeping this button active, and enabling it to open relevant Properties
> dialog, has additional benefit of providing useful information to the user:
> clicking it, user can learn where does this information come from. It is
> self-documenting and educating.

ATM it only apply in one case >Document>Sender.
Plus: The Help-button directly next do it is meat for explanation and does it:
>"Inserts fields containing user data. You can change the user-data that is displayed
>by choosing Tools - Options - LibreOffice - User Data."

(In reply to Mike Kaganski from comment #18)
>I see *absolutely no* downsides in keeping it. Do we have a bug report like "I see this button (if it would work)

It hurts my eyes to see in button inactive all the time but only active in 1 out of 48 cases! But sure, I also can write a bug-report for it.
Comment 22 Mike Kaganski 2020-10-20 18:18:46 UTC
(In reply to Sascha Z from comment #21)
> It hurts my eyes to see in button inactive all the time but only active in 1
> out of 48 cases! But sure, I also can write a bug-report for it.

So doesn't the suggestion "let's enable it - make it active - also for this, and for this, and also for those fields, so it would be active not only for 1 case" address that?
Comment 23 S.Zosgornik 2020-10-20 21:37:56 UTC
(In replay to Mike Kaganski from comment #22)
>So doesn't the suggestion "let's enable it - make it active - also for this, and
>for this, >and also for those fields, so it would be active not only for 1 case"
>address that?
(In reply to Sascha Z from comment #14)
> Do you know any other suggestions for using this very button?
(In reply to Mike Kaganski from comment #15)
> No; but I don't think we need more suggestions. Simply when any field uses
> some property available elsewhere, the Edit button *should* be used to open
> that place directly; that's how it was designed.

Than you should start making suggestions where this button should lead to. So far we have only the Document Properties which is declared as very limited editable by yourself.
Comment 24 sdc.blanco 2020-10-20 23:18:54 UTC
(In reply to Heiko Tietze from comment #17)
> I still vote for keeping this workflow and dropping the Edit button since 
> it is used for only one feature with not much benefit. => NAB
Was not trying to suggest it was a bug.  More a matter of good UI design.

Just checking that point a and b, at end of comment 6, have been understood: - what is the purpose of popping up the "Edit Dialog" box for fields that cannot be edited from that dialog box?

  Comments
  Keywords
  Subject
  Revision Number
  Title

Of course, no harm done -- just wasted time (and some possible confusion about why one is offered an editing dialog that does not "edit").

Simple solutions, as you already noted, for these particular types (minus Revision Number) are to go directly to Files - Properties - Description (why introduce an extra click in the process with an Edit button through Edit Dialog?)

From user POV, field "type" cannot be identified.  The "habit" is to double-click the field to edit.  The "double-click" means "I want to edit that field"  (not "take me always to the same "Edit Dialog").

Having double-clicked, the expectation is that the software will make an appropriate response to that "edit request". 

If the field is a variable, Edit Dialog is meaningful.  
If the field is "Revision Number", then a pop-up box ("Revision Number cannot be edited") might be more appropriate.
etc., etc...

Not trying to "sell" the idea -- just making sure that the situation is appreciated and considered acceptable.
Comment 25 Mike Kaganski 2021-05-05 08:11:02 UTC
(In reply to S.Zosgornik from comment #23)
> Than you should start making suggestions where this button should lead to.
> So far we have only the Document Properties which is declared as very
> limited editable by yourself.

Ref: https://ask.libreoffice.org/en/question/307784/docinformation-fields-cant-be-updated/

Custom document properties (from this "DocInformation" tab discussed here) should be editable from this Edit button. The button should lead to File->Properties dialog, at its "Custom Properties" tab, with the relevant property selected.
Comment 26 Mike Kaganski 2021-07-13 09:52:36 UTC
Just now from IRC:

> jmd: I'm trying to update the "Title" field in a document, but when I double
> click on it, the "Edit" box appears greyed out.  Is this a problem with
> permissions or what?
> mikekaganski: jmd: no, it is just a read-only field, which reads data that
> is defined elsewhere (File->Properties->Description)
> jmd: mikekaganski: I see (now).  Thanks.
> jmd: I bet I'm not the first person to find this utterly confusing.

Naturally, the user expectation is being able to click Edit - and if that would open File->Properties->Description, it would be useful.