# Remove *user* from the Agendav database. This should remove him
# from _every_ table in which he is referenced.
#
+ # We do not raise an error if the user doesn't exist. This is due to
+ # an unfortunate problem with the "user exists" check in AgenDAV.
+ # The AgenDAV "shares" table is not tied directly to a username, so
+ # we are forced to use a regexp match to decide what rows to delete
+ # from that table. We do so regardless of whether or not the username
+ # exists in the "prefs" table, because that table stores only non-
+ # default preferences -- not all users' preferences.
+ #
# @param user [User] the user to remove.
#
def remove_user(user)
- raise NonexistentUserError.new(user.to_s()) if not user_exists(user)
-
sql_queries = ['DELETE FROM prefs WHERE username = $1;']
- sql_queries << 'DELETE FROM shared WHERE user_from = $1;'
- connection = PGconn.connect(@db_host, @db_port, @db_opts, @db_tty,
- @db_name, @db_user, @db_pass)
-
- sql_queries.each do |sql_query|
- connection.query(sql_query, [user.to_s()])
+ # The "shares" table contains principal URLs, and the "@" symbol
+ # is usually encoded to "%40". These queries do a regex match on
+ # the username after replacing the "%40" with a "@".
+ #
+ # As a precaution, I haven chosen not to delete based on the
+ # "calendar" field here. Nobody should have a calendar named
+ # "user%40example.com", but it's not impossible -- and we don't
+ # want to delete that calendar when the not-necessarily-related
+ # "user@example.com" account is removed. And the usual appearance
+ # of the user's email address in the "calendar" field happens when
+ # he is also the owner, so the calendar does get deleted in the
+ # normal situation.
+ sql_queries << "DELETE FROM shares WHERE REPLACE(owner,'%40','@') ~ $1;"
+ sql_queries << "DELETE FROM shares WHERE REPLACE(\"with\",'%40','@') ~ $1;"
+
+ connection = PG::Connection.new(@db_hash)
+ begin
+ sql_queries.each do |sql_query|
+ connection.sync_exec_params(sql_query, [user.to_s()])
+ end
+ ensure
+ # Make sure the connection gets closed even if a query explodes.
+ connection.close()
end
-
- connection.close()
end
end