Return-Path: Delivered-To: apmail-incubator-esme-dev-archive@minotaur.apache.org Received: (qmail 77397 invoked from network); 5 Oct 2009 05:47:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Oct 2009 05:47:33 -0000 Received: (qmail 3327 invoked by uid 500); 5 Oct 2009 05:47:33 -0000 Delivered-To: apmail-incubator-esme-dev-archive@incubator.apache.org Received: (qmail 3278 invoked by uid 500); 5 Oct 2009 05:47:33 -0000 Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: esme-dev@incubator.apache.org Delivered-To: mailing list esme-dev@incubator.apache.org Received: (qmail 3268 invoked by uid 99); 5 Oct 2009 05:47:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Oct 2009 05:47:32 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of benewu@gmail.com designates 209.85.211.188 as permitted sender) Received: from [209.85.211.188] (HELO mail-yw0-f188.google.com) (209.85.211.188) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Oct 2009 05:47:23 +0000 Received: by ywh26 with SMTP id 26so2122066ywh.12 for ; Sun, 04 Oct 2009 22:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=zt44C9VHoFHpaSikcAAs7A35UfO5t5ZaGIYW0Ch8FnQ=; b=JI96wdVUGpC9wVkPtCAEpq1evxl0LQRVwY0VDpE2nGqmhLQdRxUzeGKrWhD8tvZ5t7 UA/PP514pxyiMsGLDh4lEhKT0NfnNd9BZ8w1nl3WveJ5d+I6F9DVWNOFKwpjhnj75BFU 337915dvpLZQsxldkght++MBzL3lxMu3TApgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=OoVVJ60IKdc4XTWyqMDLbWirC1irwniHoBY5RqjEeaUlh63+EHxsIcX58uUgMuKFC8 lmqzV3otG0I6QEwoiEQD/TSU/tsGDWhEqg2zrck4Jbq4tEK82AlNMBj3s3/yQmL2BU0Q wHTP9msYmEW3FnANHzadjGB3LEbFAu2bQqwng= MIME-Version: 1.0 Received: by 10.100.239.2 with SMTP id m2mr4864967anh.20.1254721622757; Sun, 04 Oct 2009 22:47:02 -0700 (PDT) In-Reply-To: <4db64d890910010530h4377ce8eq698597fc8e48e483@mail.gmail.com> References: <4db64d890910010037o15c7d7du785deb893852e15c@mail.gmail.com> <4db64d890910010339m64f516d5p7c362f38c5a3f97f@mail.gmail.com> <4db64d890910010425n7b3f6ae6nd0cc820e3167ba59@mail.gmail.com> <4db64d890910010443l22e94871xab078a7a7a73a960@mail.gmail.com> <4db64d890910010530h4377ce8eq698597fc8e48e483@mail.gmail.com> Date: Mon, 5 Oct 2009 13:47:02 +0800 Message-ID: <4db64d890910042247h18a3e807tca6683fd11e08475@mail.gmail.com> Subject: Re: Deleting user from access pool From: Xuefeng Wu To: esme-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=0016e6d2716f9dd014047529a443 X-Virus-Checked: Checked by ClamAV on apache.org --0016e6d2716f9dd014047529a443 Content-Type: text/plain; charset=ISO-8859-1 Although I do not like delete any data from DB, but consider performance, I do it. For I'm not family with ESME. The things is not easy I image after I delete user from access pool. 1. After I delete user from access pool, the message is send to his/her mailbox as before. Is there any cache and I need refresh the cache after delete user from pool? 2. After delete user from access pool, user can not his/her message which already in mailbox before. Will check access pool when access mailbox? I'm trying to understand more about ESME, especially Action! On Thu, Oct 1, 2009 at 8:30 PM, Xuefeng Wu wrote: > WoW, I think we should not delete any data from physical DB. > > > On Thu, Oct 1, 2009 at 8:27 PM, Vassil Dichev wrote: > >> > So we only need to add a new attribute validate at Privilege and modify >> > Privilege.hasPermission. >> > >> > def hasPermission(userId: Long, poolId: Long, permission: >> > Permission.Value) = Privilege.find( >> > By(user, userId), >> > By(pool, poolId), >> > *By(validate, true)* >> > ).map(_.permission.is >= permission).getOrElse(false) >> > >> > It's done at server-side? >> >> ...or delete existing permissions for this user. This way we won't >> also have to edit the find*Pools methods. >> >> When a user has no permission in a pool, of course messages will not >> be sent to their inbox anymore. >> > > > > -- > Global R&D Center,Shanghai China,Carestream Health, Inc. > Tel:(86-21)3852 6101 > -- Global R&D Center,Shanghai China,Carestream Health, Inc. Tel:(86-21)3852 6101 --0016e6d2716f9dd014047529a443--