<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - Deleting the source CSV file of an Address List should delete it from data sources" href="https://bugs.documentfoundation.org/show_bug.cgi?id=125331#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - Deleting the source CSV file of an Address List should delete it from data sources" href="https://bugs.documentfoundation.org/show_bug.cgi?id=125331">bug 125331</a> from <a class="email" href="mailto:lionel@mamane.lu" title="Lionel Elie Mamane <lionel@mamane.lu>"> Lionel Elie Mamane</a> <pre>(In reply to Buovjaga from <a href="show_bug.cgi?id=125331#c2">comment #2</a>) > Having data sources registered inside LibreOffice to be decoupled from files > on disk seems like a rather deliberate decision. Yes. And the story is even one more step remote from the actual file with the actual data. What is registered is the path to an .odb file. Here, that odb file has a separate .csv file as actual data source. I share your sentiment. I very definitely don't want the database registration to automatically disappear when the .odb file is not found, or the underlying data source cannot be connect to, or anything like that. However, I also mostly get the reporter's point. In the scenario he lists, LibreOffice hand-held the user so much in the creation of the data file, the .odb file (pointing to the data file) and the registration of the .odb file (technically three separate thing) that the user has no way of being conscious that there is _at_ _all_ a this three layer structure, much less understand it. That is a suboptimal user experience. I have no simple idea to enhance it.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>