Version: 1.13.0 (using 4.3.90 (KDE 4.3.90 (KDE 4.4 RC1)) "release 210", KDE:KDE4:Factory:Desktop / openSUSE_11.2) Compiler: gcc OS: Linux (x86_64) release 2.6.31.5-0.1-desktop I have a adressbook group named "XXXXX". I chose as a mail receipient this group (auto completion) "XXXXX". The mail cannot be sent and the mail server responds with "invalid receipient: XXXXX@mycomputername" So kmail seems not to replace the adress-group name with its mail addresses.
*** Bug 228446 has been marked as a duplicate of this bug. ***
*** Bug 228722 has been marked as a duplicate of this bug. ***
Why is this LO priority? Heavy users of distribution lists in 4.4.1 are missing this feature and all I can tell them to do is revert to 4.3.5.
I had the same problem with Fedora 12 and kde-4.4.0. Today I updated it to kde-4.4.1 from testing repository. The problem still exists. Is there any timeframe when it is going to be fixed? It is not a good idea to break functionality which was used in kde-4.3.
Same problem with the Debian 4.4.1-rc packages...
Same problem with 4.4.2 Additional: - cannot select a distribution list using "select recipient": Preselect "Distribution Lists" ==> no selectable items in list below. - When generation a distribution list out of a sender list with multiple addresses in one to/cc field using "Save List..." does not result in a use/viewable list definition. Only single-address-items are inserted correctly. - Keyboard focus handling should improved on dialogs creating and editing distribution lists.
SVN commit 1120172 by wstephens: Backport ContactGroupSearchJob changes from trunk and NepomukFeederAgentBase fixes enabling successful feeding of contact groups into Nepomuk and their querying later by kmail when expanding distribution lists. Add setLimit(1) on the group search. Also backport prerequisite changes including #include fixes, ItemSearchJob::akonadiItemIdUri() and ContactGroupSearchJob::setLimit() Backported commits to NepomukFeederAgentBase: 1095503 1109633 1109634 This does not allow selecting distribution lists in the recipients picker, but they can be entered by name in the To:, Cc: etc fields. CCBUG: 223034 M +1 -6 kdepim/libkdepim/kaddrbookexternal.cpp M +26 -4 kdepim/runtime/agents/nepomukfeeder/nepomukfeederagentbase.cpp M +25 -5 kdepimlibs/akonadi/contact/contactgroupsearchjob.cpp M +13 -0 kdepimlibs/akonadi/contact/contactgroupsearchjob.h M +5 -0 kdepimlibs/akonadi/itemsearchjob.cpp M +15 -0 kdepimlibs/akonadi/itemsearchjob.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1120172
(In reply to comment #7) > SVN commit 1120172 by wstephens: Thanks. does this mean this will be part of the next bugfix release of 4.4 (so 4.4.3)? I'm using 4.3.4 due to this bug, but would like to step to 4.4, Thanks
Yes this will be part of kde 4.4.3
It seems that in KDE 4.4.3 sending to distribution lists works. However, I can not save multiple addresses entered in KMail to distribution list using "Save list..." button. Is it necessary to file another bug? Does it work for other people?
It doesn't work for me either. The list is created, but it's empty. Currently all methods of creating or modifying contact groups fail for me.
Is anybody from KDE development team watching this? Do contact groups (or distribution lists) work for them? When they fix something for distribution lists, do they check other functionality like creation and modifying contact groups? I'm sorry, this might be offtopic here but I, and, probably, many others, got an impression that developers do not feel any responsibility when they break the functionality which was working in previous versions of KDE, and then it takes months to fix anything... What is going on? I perfectly understand that this is free software contributed by volunteers but there is no excuse if someone starts writing from scratch, breaks a lot of thing that people used in previous versions and then left it in half-functional state. I think that even in free software developers must feel some responsibility when they release anything for thousand and millions of people. This comment is not for starting a discussion. I really do not want to offend developers who spend their time for free projects, but it seems to me that it would be useful for them to know what users feel when they have to use broken software.
For me editing contact groups works, but not as good as it could be (liked much more the old addressbook), see bug 236707 But I had also problems with editing groups when I migrated to the new addressbook. There are several ressource backends now, which make things complicated.
(In reply to comment #11) > It doesn't work for me either. The list is created, but it's empty. Currently > all methods of creating or modifying contact groups fail for me. Try to use a vcard directory as akonadi-source. It works for me.
(In reply to comment #14) > Try to use a vcard directory as akonadi-source. It works for me. I just tried that. Of 22 addresses only 13 were stored. So, it still does not work as expected. Another test: sending to such a distribution list is impossible because this list is not expanded when sending mail. And, why to use several resources? If someone designed all this stuff, can (s)he explain what was real intention and how we can use it? Why not just restore the functionality that was possible in previous versions of kmail and address book?
Hej, with KDE 4.4 you should use the 'Personal Contacts' resource to store all your contacts. It provides support for contacts and contact groups and greater performance when having a huge amount of data. Why we support different resources? Well, we supported them since KDE 3.0, Akonadi doesn't bring anything new except more stable resources and a lower overall memory usage. Integrating groupware servers or external resources (facebook, google contacts etc.) is much easier now and gives us the flexibility to support whatever will come up in the future. Ciao, Tobias
(In reply to comment #16) > with KDE 4.4 you should use the 'Personal Contacts' resource to store all your > contacts. I have two resources now: akonadi-resource (type akonadi) and dir-resource (type dir). Now, I have ready to send message with 22 addresses in CC. I press "Save list...". After filling the list name and choosing the resource the list is saved but only with 13 addresses. Also addresses from this list which were already present in the address book are duplicated... Why is that? I do not need someone to appear twice or more in the address book... > It provides support for contacts and contact groups and greater performance > when having > a huge amount of data. Great! But I only need a functionality I had before. Please, make it working. > Akonadi doesn't > bring anything new except more stable resources I do not see this stability. And it seems that I'm not alone.
By the way, did anybody notice that after suspend/resume kmail does not send to distribution list? This is because the list is not expanded. Exiting and starting kmail make it work again. Does it mean that kmail looses connection with akonadi server? Now, since the bug is not fixed, how can we switch it back to "unresolved"?
It's still a bug for me. It was fixed in 4.4.3 and in 4.4.4 the previous behaviour of sending mail to listname@hostname was restored. Whoever is the responsible of this (umpteenth) regression please don't mark the bug as fixed when it's clearly not!!!
I currently have installed 4.4.3 and it works. I will install 4.4.4 and reopen if it does not work then.
(In reply to comment #20) > I currently have installed 4.4.3 and it works. I will install 4.4.4 and reopen > if it does not work then. With KDE 4.4.3: does it work after multiple suspend/resume cycles?
OK, according to Serguei it does not function neither in 4.4.3 and the reason that I didn't come across this bug in that version is that probably I didn't use this function such extensively. It is clear that this bug still exists. Maybe it is not due to kmail this time, maybe as suggested in comment #18 is a caused by a random event that makes kmail loose connection with akonadi. Can we reopen this report or should we file again this bug against akonadi?
I would like to state that, on Mandriva, this bug has persisted since kaddressbook switched to using Akonadi resources. The backported fixes introduced in KDE-4.4.3 did not make Distribution Lists work for me. I am using: * An Akonadi addressbook resource named "Personal Contacts" * The "Personal Contacts" resource is set as Standard in KDE Resources settings * My Distribution List (Group) and its e-mail addresses are in "Personal Contacts" * Semantic Desktop is enabled - Nepomuk processes are running * Strigi File Indexer is enabled and running Any attempt to post to a Distribution List results in a 5.1.1 server error because the address DistributionListname@localhost is returned for the Distribution List entered in a To or Cc entry field in the KMail Composer when the e-mail is sent.
This feature is now working in Mandriva. I believe it started working with the arrival of a new Akonadi Agent named "Nepomuk Contact Feeder" which is visible on the Akonadi Console Agents tab. Contrary to information supplied about backported functionality for 4.4.3, it does appear possible to send to distribution lists using the Select button and selecting the list from the choice box (in the KMail composer). Regards, Neil Darlow
I have to reopen. I don't know what update is responsible for this. but: - first I only upgraded the kde-4.4 libs and base to 4.4.4. then the bug reappeared. and even after upgrading the rest (kde pim,..) the bug stays. so I reopen.
Created attachment 48266 [details] Empty DL This screen shots shows that the DL is expanded whit three empy contacts
Created attachment 48267 [details] Drug&Drop Not working
Still not fixed in 4.5. Seriously?
For my original problem works in 4.5, so I close again. For any other problems (like drag&drop), please open a new bug.
I am using kontact 4.8.0 and that bug affect me to
Here too in 4.8.0 (openSUSE 12.1): Messages to distribution lists are being sent to invalid receipient "listname@mycomputername"
still not working in 4.8.1
Used to work n with 4.7.x. Now on 4.8.1 FC16 does not work again.
Using KDE 4.9.00, KMail 4.9.00 and Kaddressbook 4.9.00 When selecting a group with the button "select", the group does not expand and sending to the group fails because kmail will use "groupname@hostname" instead of the mail-addrresses of the group members
Confirmed for Debian wheezy: Qt: 4.8.2 KDE Development Platform: 4.8.4 (4.8.4) KMail: 1.13.7
Confirmed for Kubuntu with KDE 4.10.00 (kubuntu-ppa) This is absolut _basic_ functionality. And it does not work for _years_ now! Please make it work!
Doesn't work either on opensuse 12.2, kde 4.10. And I thought gone where the days when upgrading kde would inevitably break kmail and necessit hours of fidgeting, reconfiguration and workarounds... Well, at least one can now get rid of nepomuk and have a working email client (albeit with no distribution lists). Oh wait, wasn't that what we had when this all started?
same here, 4.10.3 (kubuntu 12.04): Messages to distribution lists are being sent to invalid receipient "listname@mycomputername" - this bug has been resolved several times in 4.x history, but keeps coming back over and over again, what a PITA
same problem in Kubuntu 13.04 with KDE 4.11
(In reply to comment #38) ok, seems to be fixed, finally :D (using kmail from kde 4.11.1, kubuntu 12.04 packages).
resolving then. thanks for reporting
I am really sorry to say that, but, no, it still doesn't work in kde 4.11.1, opensuse packages. A _single_ email now gets send to server (google in my case) for delivery, but the recipient is still list_name@computer_name. Bummer. What should I do?
Created attachment 82326 [details] Workaround for akonadi/nepomuk startup ordering I have found that this problem is caused by a startup ordering problem relating to akonadi and nepomuk. Specifically, for akonadi address resource indexing to work correctly, nepomukfilewatch and nepomukfileindexer must start before akonadi_nepomuk_feeder. If this does not happen then addresses are not indexed and address expansion fails. This script detects the condition that akonadi_nepomuk_feeder is started before nepomukfilewatch/nepomukfileindexer and, in that case, it sends a HUP signal to akonadi_nepomuk_feeder which causes it to respawn. Indexing will then commence correctly. Copy the script to .e.g. /usr/local/bin and make it executable then add it to your KDE autostart as a script. It will execute at the next login. I have been running this script on fedora-based netbook and desktop systems for months now and my akonadi address resource expansion works flawlessly. Regards, Neil Darlow
Kubuntu 13.04, KDE 4.11.1 and it dies not work. Will try the script
@Neil Thanks for the script!! I am not sure if this is what "solved" it for me or the good ol' rm -rf `find ~/ -name "*nepomuk*"` that I had forgotten to run before trying to send an email, silly me. Anyway, it now works for me (at least until the next upgrade ;-).
(In reply to comment #45) > rm -rf `find ~/ -name "*nepomuk*"` Half off-topic, but it's generally safer (and clearer) to say find ~/ -name "*nepomuk*" -delete The order is important here!
(In reply to comment #46) > (In reply to comment #45) > > rm -rf `find ~/ -name "*nepomuk*"` > > Half off-topic, but it's generally safer (and clearer) to say > > find ~/ -name "*nepomuk*" -delete > > The order is important here! what will this command do? will it delete all nepomuk files and configs? what impact has this command on my nepomuk configuration? the workaround script has not worked for me.
(In reply to comment #47) > (In reply to comment #46) > > (In reply to comment #45) > > > rm -rf `find ~/ -name "*nepomuk*"` > > > > Half off-topic, but it's generally safer (and clearer) to say > > > > find ~/ -name "*nepomuk*" -delete > > > > The order is important here! > > what will this command do? will it delete all nepomuk files and configs? > what impact has this command on my nepomuk configuration? > > the workaround script has not worked for me. I can live without working contact lists, but nepomuk is very important for me an my daily work
Hi, On Monday 16 September 2013 09:07:16 you wrote: > the workaround script has not worked for me. If you look at the Agents tab in Akonadi Console, what is the status of Akonadi Nepomuk Feeder? It should indicate "Indexing completed". If it indicates that is is waiting for Nepomuk to start or, after a while, Nepomuk is not running then that is the error condition the script attempts to address. You did chmod +x the script and add to KDE autostart? Regards, Neil Darlow
(In reply to comment #49) > Hi, > > On Monday 16 September 2013 09:07:16 you wrote: > > the workaround script has not worked for me. > > If you look at the Agents tab in Akonadi Console, what is the status of > Akonadi Nepomuk Feeder? > > It should indicate "Indexing completed". If it indicates that is is waiting > for Nepomuk to start or, after a while, Nepomuk is not running then that is > the error condition the script attempts to address. > > You did chmod +x the script and add to KDE autostart? > > Regards, > Neil Darlow Yes I have done that. But is it really necessary to run the script each time when I log to run the script? When I run the script manually I get an exception: ./feeder-restart: 11: ./feeder-restart: Syntax error: "}" unexpected
Hi, On Monday 16 September 2013 09:24:53 you wrote: > Yes I have done that. But is it really necessary to run the script each time > when I log to run the script? In the sense that the start-up order of nepomukfilewatch/nepomukfileindexer and akonadi_nepomuk_feeder is not guaranteed, yes it is necessary to check this condition at login when these processes are started. > When I run the script manually I get an exception: > ./feeder-restart: 11: ./feeder-restart: Syntax error: "}" unexpected How did you install the script? Was it by copy and paste or by moving the downloaded file? This is standard Bash scripting and shouldn't present a syntax error unless the file is somehow corrupted. Regards, Neil Darlow
(In reply to comment #51) > Hi, > > On Monday 16 September 2013 09:24:53 you wrote: > > Yes I have done that. But is it really necessary to run the script each time > > when I log to run the script? > > In the sense that the start-up order of nepomukfilewatch/nepomukfileindexer > and > akonadi_nepomuk_feeder is not guaranteed, yes it is necessary to check this > condition at login when these processes are started. > > > When I run the script manually I get an exception: > > ./feeder-restart: 11: ./feeder-restart: Syntax error: "}" unexpected > > How did you install the script? Was it by copy and paste or by moving the > downloaded file? > > This is standard Bash scripting and shouldn't present a syntax error unless > the file is somehow corrupted. > > Regards, > Neil Darlow Just downloaded the file from here, run chmod und executed the file. But sorry, this was not the complete error output: ./feeder-restart: 9: ./feeder-restart: function: not found Aufruf: grep [OPTION]… MUSTER [DATEI]… Try 'grep --help' for more information. ./feeder-restart: 11: ./feeder-restart: Syntax error: "}" unexpected
(In reply to comment #52) > (In reply to comment #51) > > Hi, > > > > On Monday 16 September 2013 09:24:53 you wrote: > > > Yes I have done that. But is it really necessary to run the script each time > > > when I log to run the script? > > > > In the sense that the start-up order of nepomukfilewatch/nepomukfileindexer > > and > > akonadi_nepomuk_feeder is not guaranteed, yes it is necessary to check this > > condition at login when these processes are started. > > > > > When I run the script manually I get an exception: > > > ./feeder-restart: 11: ./feeder-restart: Syntax error: "}" unexpected > > > > How did you install the script? Was it by copy and paste or by moving the > > downloaded file? > > > > This is standard Bash scripting and shouldn't present a syntax error unless > > the file is somehow corrupted. > > > > Regards, > > Neil Darlow > > Just downloaded the file from here, run chmod und executed the file. > > But sorry, this was not the complete error output: > > ./feeder-restart: 9: ./feeder-restart: function: not found > Aufruf: grep [OPTION]… MUSTER [DATEI]… > Try 'grep --help' for more information. > ./feeder-restart: 11: ./feeder-restart: Syntax error: "}" unexpecte the errror occurs because of this: grep $1
OK, now I have managed that the nepomuk feeder runs correct. But the distribution list does not work for me... I will wait für Kubuntu 13.10, maybe the "full system update" solves the problem. Thanks guys for your help!
(In reply to comment #54) > OK, now I have managed that the nepomuk feeder runs correct. But the > distribution list does not work for me... > > I will wait für Kubuntu 13.10, maybe the "full system update" solves the > problem. > > Thanks guys for your help! Finally, it works on my machine too. The Problem was, that nepomuk had not indexed correct the Akonadi data. I had to make Nepomuk rescan everything, now it works even when I restart my Computer without any script
Hi, On Monday 16 September 2013 21:29:19 you wrote: > Finally, it works on my machine too. The Problem was, that nepomuk had not > indexed correct the Akonadi data. I had to make Nepomuk rescan everything, > now it works even when I restart my Computer without any script The script not working for you was, I believe, because Ubuntu links /bin/sh to dash and not bash. Changing line 1 of the script to #!/bin/bash should correct this. Without the script, are you sure that Nepomuk is indexing current data? If you add a contact to an Akonadi resource and reboot does that new contact get indexed? My testing indicated that it was not. Hence the reason for creating the workaround. Regards, Neil Darlow
(In reply to comment #56) > Hi, > > On Monday 16 September 2013 21:29:19 you wrote: > > Finally, it works on my machine too. The Problem was, that nepomuk had not > > indexed correct the Akonadi data. I had to make Nepomuk rescan everything, > > now it works even when I restart my Computer without any script > > The script not working for you was, I believe, because Ubuntu links /bin/sh > to > dash and not bash. Changing line 1 of the script to #!/bin/bash should > correct > this. > > Without the script, are you sure that Nepomuk is indexing current data? If > you > add a contact to an Akonadi resource and reboot does that new contact get > indexed? My testing indicated that it was not. Hence the reason for creating > the workaround. > > Regards, > Neil Darlow Thx, now the script works
oh well, once again, after update to kde 4.13, this is not working anymore !"§%&/&[ seems to be related to change from nepomuk to baloo. WTF.
I can confirm that on Kubuntu 14.04 with KDE 4.13 and same KDEPIM version distribution lists are non functional. Yet again. Workaround: use "select" in composer window, expand your dist-list in question, select all recepients and add/cc/bcc them. Then it works
*** Bug 334794 has been marked as a duplicate of this bug. ***
With KMail 5.2.3, the list can be created, but email cannot be sent. When clicking on "Send", I get this warning popup: "The email address you entered is not valid because it does not contain a '.'. You will not create valid messages if you do not change your address." The distribution list is not expanded, and therefore KMail thinks that the DL name is an actual email address. Example: 1. Create and populate a DL named "Family, Friends" 2. Use the "Select..." button to add this DL in the "To:" field 3. Click on the "Send" button. The popup will warn you (the above message) about the email address "Family@mycomputername".
I don't use kmail anymore, how can I unsubscribe as reporter of this bug?
KMail and Kontact 5.7.3 under Fedora, still the same problem: contact groups not expanded in the composer window.
this bug keeps coming back all the time, again and again, since kde 4.x. now on kmail2 5.21.3 (22.08.3): SUMMARY kmail can't expand Address Lists STEPS TO REPRODUCE 1. create a recipients list in kmail composer, name the list, e.g. Workgroup, save it in contacts 2. write email text, select Workgroup from contacts as recipient 3. send email OBSERVED RESULT List is not resolved to Names/Addresses, but kmail wants to send to Workgroup@mydomain.de which, of course, fails.