Building Validation Rules

[agtjazz]

Hello---

In a employee/contract database..... I would like to build in some validation rules. I have the theory but really don't know how to implement it in Filemaker and would love your input or advice

If the person is Staff, Allow entry in another field-

But if not staff, then no entry can be allowed in field

If people::emp_type="Staff";job::jb_timebase can be entered

What is the syntax to allow entry or not? Am I going about this correctly?

Thanks in advance.

[T-Square]

What you're describing isn't validation per se, but rather role-based access. Just a fine point, really.

One way to limit access would be to create different layouts for the different user roles and navigate based on that--use a script that tests if emp_type="Staff" then go to the staff layout (which has that field on it), otherwise go to the limited access layout. This has the benefit that users only see what they can change (i.e., what they don't know won't hurt you), but is a hassle because you have more interface to maintain.

Another way would be to create different Privilege sets that manage the field level access. Users logged in with the lower access would see "" in that field. Of course, if *I* saw that on a layout, I'd try to find a way to get access...

HTH,

David

[agtjazz]

Thank you for the quick response… but permissions or privilege sets is not really what I am searching for.

I think I should give some more details.

There are several tables- one of which is People and another one is Job

In the People table, a field is emp_type (which Staff , Faculty, Student or Management can be entered).

In the Job table, a field is called timebase.

I only want Staff and Management type records to have a job timebase….. it doesn’t make sense for a faculty to have a job timebase- but rather a contract timebase (Contract is a whole other table)

Or another example who be:

In Job table, a field is job code… and if job code is 2390 then a new contract (or in the contract table, the cn_pk) should not be allowed to be created.

Thanks again for your time.

[agtjazz]

Would the visibility trick do this validation? How does that work? I have downloaded a sample from Database Pros and am starting to study John Mark Osborne's article.

Any pointers or links will be appreciated.

[Søren Dyhr]

I would agree with T-Square ...this is not validation. But yes you should be able use the userName as primary key for the visibility trick, and have the foreign key as a mulitiline of all the permission holders.

But I can't help thinking the cramming as much as posible horror vacui'ish into the same layout, hardly conveys a comfy userinterface. Why not deal with this via scripted access to members only areas in the solution???

The visibility trick as such kind of circumvent HUI rules established in the Mac OS at least ...where recognizable metaphors are expected.

--sd

[agtjazz]

Ok obviously I am not explaining my situation correctly..... sorry for the confusion

Here goes

I only have 1 user with no user credentials necessary at this point.....

Staff or Faculty is Emp Type for all personnel in database (in job table, emp_type is a field with Staff, Faculty, Student or Management as acceptable answers)

If John is Staff, then I want timebase (another field in the job table) to be able to be populated

If John is Faculty, then timebase in the job table should not allow my 1 user to enter stuff into the field....

ANOTHER EXAMPLE-----

1 user database

if "field x" is apple, then allow "field y" to be populated

if "field x" is orange, then allow "field y" to NOT be populated.....cursor won't even go in field

I do appreciate the advice and am sorry for any confusion.

[agtjazz]

I think a visual will aid my explanation so I watered down a database to show what type of validation rules I am trying to build.

Your assistance is greatly appreciated.

HR.zip

[agtjazz]

If anyone has any input on the above, I would really really appreciate it.

Thanks in advance!

[agtjazz]

Test--did this post?

[Søren Dyhr]

Using the visibility trick inside a portalline is not possible because a portal in a portal won't work.

However if the portal doesn't have a scroll bar attached would it be possible to cut the portal up in two halves and the visibility field should be outside each of the two portals squeezed into it's original position. Say the portal has 10 rows, then would you be able to grap each portal rows ID and the field where the magic word works.

So it's possible, but there is a lot of spit and polish you need to throw after the layouting.

--sd

test.zip

[agtjazz]

Thanks for all your help.... I will take a look at the sample you provided and try to make it work.

Thanks again

[agtjazz]

Is the portal the limitation on building these rules? If I had a normal layout (no portal), could I easily build in validation rules?

Thank you

[Søren Dyhr]

Well I would say so or rather the scrollbar is, but then in a protal free layout should each line in a list have it's own relation, and you would always be stucked with a certain max of lines!

Go to Kachels whitepaper and read about tiered relations!

--sd

[agtjazz]

I have searched & googled, but can't seem to locate any link in English. <:>

[Søren Dyhr]

Try this:

http://www.foundationdbs.com/Downloads/WhitePaperForFMPNovices.pdf

--sd

[agtjazz]

As always- your assistance is very appreciated!

Thanks bunches

and hope your day is pleasant!

-Pali