After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 503954 - Google Calendar plugin won't accept non gmail usernames
Google Calendar plugin won't accept non gmail usernames
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Calendar
2.22.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
: 506580 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-12-17 00:36 UTC by nyall
Modified: 2013-09-13 00:57 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
patch for incorrect handling of google calendar usernames (830 bytes, patch)
2007-12-19 04:45 UTC, nyall
committed Details | Review

Description nyall 2007-12-17 00:36:43 UTC
Please describe the problem:
Currently, the google calender plugin (google-account-setup) only accepts usernames ending in @gmail.com. However, google calender has the option to use a custom domain name (via google apps), so usernames @ any domain should be accepted. Entering user@domain.com in the plugin setup currently results in the incorrect username user@domain.com@gmail.com being saved.

I believe the best way to fix this is to modify plugins/google-account-seutp/google-source.c, and change line 186-188 from:

if (!g_str_has_suffix (user, "gmail.com\0")) {
        user = g_strconcat (user, "@gmail.com", NULL);
}

to instead check if the username already contains any valid domain suffix, and if not, then apply the @gmail.com suffix.



Steps to reproduce:
1. Add a new google calender with the username "user@domain.com"



Actual results:
The username is incorrectly saved as "user@domain.com@gmail.com"


Expected results:
Username should be saved as "user@domain.com"

Does this happen every time?
Yes

Other information:
Comment 1 André Klapper 2007-12-17 10:26:18 UTC
hi nyall, thanks for the report. interested in providing a patch and attaching it here?
Comment 2 nyall 2007-12-18 02:46:04 UTC
Honestly, I've tried,  back my c/regular expressions skills aren't up to scratch, so I'm not sure the most elegant way to replace

g_str_has_suffix (user, "gmail.com\0")

with a generic email-validation function would be. 

If someone can help me out with this I'd be happy to submit a patch :)
Comment 3 André Klapper 2007-12-18 12:26:10 UTC
hmm, i don't expect regex magic here, i think the email account creation code in evolution also only parses for a "@".
proposal: if there's no "@" in the text entered, then append @gmail.com, if not, then not. :-)
(just my two cents, i'm not a developer.)
Comment 4 nyall 2007-12-19 04:44:58 UTC
Ok, here's a patch. It uses the same is_email function from /mail/em-account-editor.c


Comment 5 nyall 2007-12-19 04:45:39 UTC
Created attachment 101234 [details] [review]
patch for incorrect handling of google calendar usernames
Comment 6 Srinivasa Ragavan 2007-12-19 07:31:11 UTC
Nyall, It looks fine. Just attach patches here after with ChangeLogs. Approved to commit. (If you don't have commit rights, we would commit it during the release)
Comment 7 nyall 2007-12-19 23:15:38 UTC
No commit rights sorry - I'll leave it in your hands :)

Thanks for the assistance!!
Comment 8 Suman Manjunath 2007-12-23 09:42:23 UTC
Patch committed to SVN trunk as r34732
(http://svn.gnome.org/viewvc/evolution?view=revision&revision=34732)
Comment 9 nyall 2007-12-23 22:51:16 UTC
Thanks for committing this. I've also posted what is essentially "part 2" of this issue in http://bugzilla.gnome.org/show_bug.cgi?id=504783

It's a small change needed in e-d-s, to the auth string in servers/google/libgdata-google/gdata-google-service.c 
This fixes some remaining authentication issues with custom domains. I'd appreciate it if you could take a quick look at that patch too!
Comment 10 André Klapper 2008-01-02 09:55:45 UTC
*** Bug 506580 has been marked as a duplicate of this bug. ***