Description: For (mail manage wizard) in (Tools) and after creating a new Address List and deletes it completely from the database his name remains in the address list board Steps to Reproduce: 1.open LibreOfficeDev 2.Choose Writer Document 3.In tools tab choose (Mail Manage Wizard) 4.In the step (Select Starting Document) keep the default choice and click on (Next) 5.In the step (Select Document Type) keep the default choice and click on (Next) 6.In the step (Select Address List) click on the button (Select Address List) 7. In dialog box of (Select Address List ) click on the buttons <Create> 8.Give a title for the list and click on (Ok) 9.Give a name for the file and save it in the database 10.Close completely LibreOffice 11.Deletes the file of the Adress List completely from the database 12.Repeat the steps until step 06 Actual Results: The name of the adress list file that already been deleted remains in the address list board Expected Results: The name of the adress list file that already been deleted must be remouved to the address list board Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info:
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone else confirms it.
I don't think we should do this. I don't want to seem dictatorial in closing this, so I will ask design team. Having data sources registered inside LibreOffice to be decoupled from files on disk seems like a rather deliberate decision. If we change this, I think users might see it as data loss.
(In reply to Djaafar Benchikh from comment #0) > 8.Give a title for the list and click on (Ok) It's the addressee's title, like Prof. Dr., PhD, or MD. The list is identified by the file name. (In reply to Buovjaga from comment #2) > If we change this, I think users might see it as data loss. Point here is that the file was deleted on the hard-disc but is still referenced in the DB. Seems to be a general issue for Base. We could remove the entry, gray it out, or create the file automatically (bad solution as you cannot revert the deletion). And keep the entry as it is (WFM). At the start center we have a similar problem since you may store data on volatile discs (USB stick) and the recently used file is just temporarily not available. What do you think, Gabor, Robert, Linonel?
(In reply to Buovjaga from comment #2) > 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.
(In reply to Lionel Elie Mamane from comment #4) > I have no simple idea to enhance it. What do you think about my idea to gray-out those entries where the data is (temporarily) not available?
(In reply to Heiko Tietze from comment #5) > (In reply to Lionel Elie Mamane from comment #4) > > I have no simple idea to enhance it. > > What do you think about my idea to gray-out those entries where the data is > (temporarily) not available? By data, you mean the actual data, not the .odb file. How do you determine that? You can't just try to connect: - can take network requests, time (large list), consume client licence spot on SQL server, ... - you may be missing a password; you will not ask the password of all entries(!). How will you reliably determine if the connection failed You want to limit it to non-network requests? You will still need to open each .odb file, see what it connects to (embedded data? network database? another data file?) and make a decision. Also not good for performance, a file can also be on a slow NAS / network filesystem over a VPN over slow Internet, ... If you mean checking whether the .odb file is reachable, that can work, and I would not oppose the patch. Not sure users will understand the difference between the odb and the data, but <shrug>
So since we have to find a generic approach it's (almost) impossible to check whether actual data are accessible or not (see c6). The only option is to remove the database when the connection fails (on confirmation, of course), and that's not what is requested here. So let's close the issue as WF.