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"
(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.
Dear sdc.blanco, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/91c11939b477a0542edb05c45cd735752accbb40 Resolves tdf#137298 - Show document info for respective fields It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.