# More than one criteria in business logic

**URL:** <https://www.ruby-forum.com/t/more-than-one-criteria-in-business-logic/170688>\
**Category:** Rails\
**Created:** [June 21, 2009, 8:05am UTC](https://www.ruby-forum.com/t/more-than-one-criteria-in-business-logic/170688 "2009-06-21T08:05:31Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![talex83](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/54ee81/32.png) [@talex83](https://www.ruby-forum.com/u/talex83)\
**Post date:** [June 21, 2009, 8:05am UTC](https://www.ruby-forum.com/t/more-than-one-criteria-in-business-logic/170688/1 "2009-06-21T08:05:31Z")

</div>

Hello all!

I’m looking to get some help answering a design problem I’m facing. I’m  
definitely familiar with how models house all the business logic, but  
when it RoR, I’m somewhat confused 🙂

If I have Users, and they have a HABTM relationship to Messages:

Users  
o ID  
o Name

Messages  
o ID  
o Body  
o Public

Users\_Messages  
o User\_ID  
o Message\_ID

What is the best practice to check two criteria for a kind of  
authorization check?  
The first being simply evaluating the HABTM relationship using  
user.messages.  
The second being that a user can see all messages where Public==true?

Both are separate, yet I want to be able to generate one list from these  
two separate criteria in one call, mixing the results.

Hopefully I’m clear enough, thanks in advance for any help!

---

<div class="post-metadata">

**Author:** ![talex83](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/54ee81/32.png) [@talex83](https://www.ruby-forum.com/u/talex83)\
**Post date:** [June 21, 2009, 10:56am UTC](https://www.ruby-forum.com/t/more-than-one-criteria-in-business-logic/170688/2 "2009-06-21T10:56:14Z")

</div>

Hi,

why not add a named scope to messages:

named\_scope :public, :conditions =\> {:public =\> true}

So you can call either:  
user.messages  
messages.public  
or  
user.messages.public

Is that what you’re looking for?

Also, I think the standard for join tables is to name them in  
alphabetical order, so messages\_users.

Gavin

On Jun 21, 7:05 am, Alexander T. \<rails-mailing-l…@andreas-

---

<div class="post-metadata">

**Author:** ![talex83](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/54ee81/32.png) [@talex83](https://www.ruby-forum.com/u/talex83)\
**Post date:** [June 21, 2009, 10:57am UTC](https://www.ruby-forum.com/t/more-than-one-criteria-in-business-logic/170688/3 "2009-06-21T10:57:59Z")

</div>

Sorry -

That should have been, Message.public, not messages.public.  
named\_scope adds a class method

---

<div class="post-metadata">

**Author:** ![talex83](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/54ee81/32.png) [@talex83](https://www.ruby-forum.com/u/talex83)\
**Post date:** [June 21, 2009, 4:06pm UTC](https://www.ruby-forum.com/t/more-than-one-criteria-in-business-logic/170688/4 "2009-06-21T16:06:42Z")

</div>

Gavin M. wrote:

> Hi,
> 
> why not add a named scope to messages:
> 
> named\_scope :public, :conditions =\> {:public =\> true}
> 
> So you can call either:  
> user.messages  
> messages.public  
> or  
> user.messages.public
> 
> Is that what you’re looking for?
> 
> Also, I think the standard for join tables is to name them in  
> alphabetical order, so messages\_users.
> 
> Gavin
> 
> On Jun 21, 7:05�am, Alexander T. \<rails-mailing-l…@andreas-

Hey, wow! That’s really neat! I’m surprised I didn’t read about this  
in my ActiveRecord book. (I’ve only been skimming on a need-basis)

That’s neat that you can combine them, _or_ run chains of them.

So I’ve done a bit of online research about the named scopes, and I just  
want to make sure that I’m not getting in any danger by starting to  
write what may be some long named scope chains 😉

Knowing this, what I will end up doing (as my practical scenario is more  
complicated than the example provided), is write several named scopes  
and then tie them all together with one  
“canRead/canWrite/canModify/canDelete/canCreate” named scope.

Obviously I’m heading in the direction of ACL here, but on a  
per-instance level.

All suggestions and reactions are welcome 🙂