More than one criteria in business logic

Rails
1

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 :slight_smile:

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!

2

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-

3

Sorry -

That should have been, Message.public, not messages.public.
named_scope adds a class method

4

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 :wink:

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 :slight_smile: