7124835e60
If you intend to deactivate someone, and the process fails mid process, so you only delete some sessions, or some accesses, you are actually fine. The system is never left in an incomplete state. And that's really the only time we should be using transactions with sqlite3 -- to prevent actual data integrity issues. The rest of the time, we should optimize for each transaction to be as quick as possible. The sqlite3 writer lock is the one bottleneck that we cant afford to overload.
37 lines
981 B
Ruby
37 lines
981 B
Ruby
class User < ApplicationRecord
|
|
include Accessor, Assignee, Role, Transferable
|
|
|
|
has_one_attached :avatar
|
|
|
|
has_many :sessions, dependent: :destroy
|
|
has_secure_password validations: false
|
|
|
|
has_many :comments, inverse_of: :creator, dependent: :destroy
|
|
|
|
has_many :notifications, dependent: :destroy
|
|
|
|
has_many :filters, foreign_key: :creator_id, inverse_of: :creator, dependent: :destroy
|
|
has_many :closures, dependent: :nullify
|
|
has_many :pins, dependent: :destroy
|
|
has_many :pinned_cards, through: :pins, source: :card
|
|
|
|
normalizes :email_address, with: ->(value) { value.strip.downcase }
|
|
|
|
scope :alphabetically, -> { order("lower(name)") }
|
|
|
|
def initials
|
|
name.to_s.scan(/\b\p{L}/).join.upcase
|
|
end
|
|
|
|
def deactivate
|
|
sessions.delete_all
|
|
accesses.destroy_all
|
|
update! active: false, email_address: deactived_email_address
|
|
end
|
|
|
|
private
|
|
def deactived_email_address
|
|
email_address.sub(/@/, "-deactivated-#{SecureRandom.uuid}@")
|
|
end
|
|
end
|