(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.

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).

(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.

(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

(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.

(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.

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.

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 ?

(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.

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.

Or maybe activate the "Edit" button (under the Type list in Edit Fields dialog), and let it open Document Properties?

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.

(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.

(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?

(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.

(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.

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

(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"?

(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).

(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".

(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.

(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?

(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.

(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.

(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.

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.

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

Please, yes.
This is missed usability.

Situation still the same as described in comment 6.

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: cb46ad4c4602fbb6aeab482e9370e31495e12cfe
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: da-DK (da_DK); UI: en-US
Calc: CL threaded

One improvement (raised in comment 26 and comment 27) -- maybe should be broken out as separate ticket? -- is to have double-click on Title, Subject, Keywords, Comments to open File - Properties - Description tab directly, instead of the Edit Fields dialog.