Bug 133719 - Image Properties should display original filename and path by default
Summary: Image Properties should display original filename and path by default
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 156840 160082 (view as bug list)
Depends on:
Blocks: Image-Dialog
  Show dependency treegraph
 
Reported: 2020-06-06 06:28 UTC by Dihan
Modified: 2024-03-07 11:47 UTC (History)
6 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 Dihan 2020-06-06 06:28:45 UTC
Hi, using LO Writer 6.4.4.2 on macOS 10.14.6.

The Image Properties box should contain information about the image file's original name and path (if added from local filesystem).

Perhaps the Image>Properties>Options>Name field could be populated with the original filename by default?

It would be more efficient for the user if they need to locate an image inserted from their filesystem eg for editing and replacement.

Cheers
Comment 1 Dieter 2020-06-09 06:22:00 UTC
Just fpor clarification: I can't find Image>Properties>Options>Name field. But I can see Image Properties => Image => Link You can add link and name manually. Your idea is, to add this by default?

=> NEEDINFO

Related to bug 80510
Comment 2 Dihan 2020-06-12 04:52:59 UTC
I got that menu sequence by mouse Right-Clicking on Image in Writer document:

R-Click on Image>Properties>Options>Name

And Yes, the idea is to add the original filename and perhaps local file path by default (may need to add a field for filepath).

I think the original name is more important – because in my use case – I can use that to search locally for the original file.

The original filepath would also be useful, obviously as long as the original file was not subsequently moved. If this was included then the term "Original filepath" should be used with the understanding that tracking the movement of files on the local system is the User's responsibility and that this is a timestamp of the file location at the time of insertion into the document only.
Comment 3 Dieter 2020-06-12 07:40:45 UTC
(In reply to dihan.wijewickrama from comment #2)
> I got that menu sequence by mouse Right-Clicking on Image in Writer document:
> 
> R-Click on Image>Properties>Options>Name
> 
> And Yes, the idea is to add the original filename and perhaps local file
> path by default (may need to add a field for filepath).

Thanks for clarification

cc: Design-Team for further input and decision
Comment 4 Regina Henschel 2020-06-12 12:10:54 UTC
I classify such an entry as "personal information", which must be considered under security aspects. That is, it needs to be removed, if the option "Remove personal information on saving" is checked.

Another problem is, how to store such information in the file. Currently I can only think of svg:desc, which would correspond to Properties > Options > field "Description".

We had a similar request in bug 109203.

Users, who want to track such information, might use a macro, that inserts the image and writes the source path into "Description". But I am against this happening automatically.
Comment 5 Dihan 2020-06-13 06:52:41 UTC
I hadn't thought of the security aspects of the image details – it's an important point.

There are two relevant aspects to the file's original properties – it's name and it's path. 

Automatically populating an Image>Properties field with the file's location would have clear security implications by elucidating the user's local filesystem structure. 

But what would be the security risk(s) of automatically populating an Image>Properties field with the original file name?

The filename alone would be sufficient to deliver the increased usability benefit – so perhaps the name only could be autopopulated in the Properties box?
Comment 6 Heiko Tietze 2020-06-14 11:04:20 UTC
You can insert another image with this link field and it's file name but not path would be stored in <draw:image xlink:href=<filename>...> (making the image not accessible after moving just the document).

Storing just the name is not much, I guess. The intended use case might be to find out later what image exactly was used and without the path this is barely possible.
Comment 7 Heiko Tietze 2020-06-19 14:57:37 UTC
We discussed this topic in the design meeting. Storing the path is a privacy issue but we could store the name in Image Properties > Options > Name. The benefit besides better transparency what image is used, the image name is listed at the Navigator and any <Foo> is better than just Image1.

If the image name exists (source from different directories) it should extended by *_1 to _n.

It sounds also like a good plan, to delete these information if personal data is not saved. However, we didn't figure the actual option- the one under File > Properties > General is just about user's full name. Regina, what exactly do you mean?

But to deal with the issue in general, having companies in mind, we suggest to add an expert option that allows to disable the usage of file names (and keeps the current behavior).
Comment 8 Regina Henschel 2020-06-19 15:58:32 UTC
(In reply to Heiko Tietze from comment #7)
> It sounds also like a good plan, to delete these information if personal
> data is not saved. However, we didn't figure the actual option- the one
> under File > Properties > General is just about user's full name. Regina,
> what exactly do you mean?

I mean Tools > Options > LibreOffice > Security options and warnings > Options
There is the check box "Remove personal information on saving", which currently removes information from File > Properties > General. It might need to be extended to remove paths.
And there is the section "Warn if document contains recorded changes, version, hidden information or notes:" which might need to be extended to be triggered if paths are used.
Comment 9 KaylaSimson 2023-08-12 08:09:38 UTC Comment hidden (spam)
Comment 10 Heiko Tietze 2023-08-21 14:36:03 UTC
*** Bug 156840 has been marked as a duplicate of this bug. ***
Comment 11 Rafael Lima 2024-03-07 11:47:50 UTC
*** Bug 160082 has been marked as a duplicate of this bug. ***