I'll take it as read that you have a solid reason for commingling the data
from your various clients.

Something I've seen and like too is along the lines of
Filter_AfterSearch(->[Table])

So, after *any* search, you run a filter against the table. This can be
used for all sorts of things:

-- Exclude records marked 'deleted'

-- Filter records based on the user's role. A Manager might see more
records than a Floor_Worker (or the other way around.)

-- Filter by some kind of location setting.

-- What you were talking about.

You can implement the Filter_AfterSearch method however you like, I've
regularly seen big case statements with hooks for tables with special
filter rules. There are more involved ways, but a "case of" is an easy way
to start and experiment. It's also easy in Filter_AfterSearch to check that
the table has a selection before you worry about filtering it.

If you use the standard query editor, then you need code to bring up the
editor which is immediately followed by a call to Filter_AfterSearch. That
should do it. Just remember to do the same with your custom queries too so
that you don't leak data from other customers. The good part is that you
still just need the one line of code:

Filter_AfterSearch(->[Table])
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************

Reply via email to