Take a stab in the dark at AgenDAV v2.1.0 support.

[mailshears.git] / lib / mv / plugins / agendav.rb

diff --git a/lib/mv/plugins/agendav.rb b/lib/mv/plugins/agendav.rb
index 9623c4076c5cdd7f4cb535ccccea445699d25a64..4bf65834da5de2d071c664fee9d00bc826b6da15 100644 (file)
--- a/lib/mv/plugins/agendav.rb
+++ b/lib/mv/plugins/agendav.rb
@@ -28,14 +28,29 @@ class AgendavMv
     raise NonexistentUserError.new(src.to_s()) if not user_exists(src)
     raise UserAlreadyExistsError.new(dst.to_s()) if user_exists(dst)
 
-    sql_queries = ['UPDATE prefs SET username = $1 WHERE username = $2;']
-    sql_queries << 'UPDATE shared SET user_from = $1 WHERE user_from = $2;'
-    sql_queries << 'UPDATE shared SET user_which = $1 WHERE user_which = $2;'
-
     connection = PG::Connection.new(@db_hash)
     begin
+      # The "prefs" table uses the normal username as a key...
+      sql_query = 'UPDATE prefs SET username = $1 WHERE username = $2;'
+      connection.query(sql_query, [dst.to_s(), src.to_s()])
+
+      # But the "shares" table uses encoded principal URLs. For the
+      # "shares" table, we need to do a find/replace on the username
+      # with its "@" symbol translated to a "%40".
+      encoded_src = src.to_s()['@'] = '%40'
+      encoded_dst = dst.to_s()['@'] = '%40'
+
+      # Unlike in the "rm" plugin, we do modify the "calendar" field
+      # here. That's because in the usual legitimate use case, the
+      # calendar URL will change when a user moves. This will ALSO
+      # affect people who name their calendars something like
+      # "user%40example.com", but screw those people.
+      sql_queries << 'UPDATE shares SET owner=REPLACE(owner, $2, $1);'
+      sql_queries << 'UPDATE shares SET calendar=REPLACE(calendar, $2, $1);'
+      sql_queries << 'UPDATE shares SET with=REPLACE(with, $2, $1);'
+
       sql_queries.each do |sql_query|
-        connection.query(sql_query, [dst.to_s(), src.to_s()])
+        connection.query(sql_query, [encoded_dst, encoded_src])
       end
     ensure
       # Make sure the connection gets closed even if a query explodes.