Jump to content

Table Occurrences For Different Access Levels


This topic is 3708 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I'm revamping a fairly complex database (anchor-buoy, separated-data-model, 300+ table occurrences).  There are a number of root table occurrences that refer to the same table but are distinguished by access level.

 

In other words, based on the Students table, there is a root table occurrence Students_SV  (for a student's view of their record) and a root table occurrence Students_AV (admin view of a student's record) .  Then there are separate layouts for Student View and Student Admin view which each refer to their respective table occurrence.  This seems unnecessarily complex (there is a lot of redundancy between the Students_SV and Students_AV table occurrence chains).  Is there any reason not to just use the Students table as the table for both Student View layout and the Admin layout for viewing Students?  If, say, there are relationships that you only want accessible to an Admin, isn't simply not including them in the Student view layout enough security?

 

 

 

Thanks for any advice!

 

Link to comment
Share on other sites

Wim please what does security see?  Is its access calculation evaluating from context of server client?  Or if not based upon a table occurrence, how can it evaluate a calculation?  And is security client-based like global fields in that if I put a calculation including a global variable for example it will know it means to apply to only this one person differently than others with their own global variable values?

 

Thank you.  Perspective.  That is the word I was looking for.  And does Perform Script on Server change that perspective?  Wonderful thoughts crayfish!

Edited by Charity
Link to comment
Share on other sites

Calculations are always based on a TOs context but that has nothing to do with security.

 

If you want to prevent the user from seeing certain records in a table, you set that up in the privilege set and that one is based on the actual table, not on any TO.

 

Global fields and Global variables are unique to the user's session, so one user can not see what the other has in one of those.

Be careful however when using globals (fields/variables) in field calculations; you may be introducing bad performance that way:

- In some cases FMS can evaluate a calculation instead of the client.  But if you include something that is user session specific, FMS will send the client the data and the client needs to evaluate the calculation

- if your calculation becomes unstored because of the global where it otherwise could be stored

 

Perform Script On Server behaves just as if a new user logs into the database.  It does not inherit anything at all from session that is called from (no found set, no context, no globals,...)

Link to comment
Share on other sites

I can not test yet. No server yet.  But I am trying to get the basics in place based upon some assumptions.

 

We will not allow deleting records but only flag them and I can include that flag in security no problem then right?  And if a salesman can only see a certain territory then I can include territory in their security.  This will save me always having to filter out or otherwise constrain finds down to what I want on higher-up basic restrictions.

 

So finds will be easier if I use security for the things which are always true and stored or indexed.  But if the rules can change so the calculation would need to be unstored whether global or variable then it is better to handle those restrictions in other ways.  I think in those cases, I would want to use Perform Script On Server so it would be faster and not download any records.  So I would need to pass my criteria in its script parameter and then it will perform the find and then it can exit and pass the IDs of that found set back to me.  Am I correct please Wim?

 

But since Perform Script on Server is its own client and not the current user requesting the script to run, I will need to include the restrictions normally applied by security to the current User.  So I have to include <> deleted, Territory = "Blane" etc in the find that FMS server runs.  Am I finally getting it?  Thank you for responding very much.

Link to comment
Share on other sites

No.

PSOS is performed as a new session of the current user.

It knows the user name and privilege set and extended privileges and carries all the restrictions associated with the logged in user.

Link to comment
Share on other sites

  • 2 weeks later...

Perform Script On Server behaves just as if a new user logs into the database.  It does not inherit anything at all from session that is called from (no found set, no context, no globals,...)

 

Thank you both very much for helping me understand this.  So PSOS is a new session for the current user running the script.  I read that the file must restart or how to say, re-login and run the starting file's script again?

 

So this takes time.   Everyone says using PSOS is very fast but when do I know if it is worth it to use PSOS since part of its speed savings might be lost because of the time it takes it to log in again or restart?

 

Can I make my opening script see if it is PSOS and not go through all the bells and whistles I have in startup?  Can I branch it or somehow make it restart very fast if PSOS?  In start I will have it loop and set all tables to zero records.  I want to skip that, for once, if PSOS does it, won't I?  And if it must restart, do I need to include my startup or OnFistWindow script within the PSOS script?

 

The questions should slow down since I received email today that our new hardware will be delivered in two weeks!  I am stoked.  Then I can begin seeing this stuff for real on a real server machine and everything.  This wait has held me up but luckily your assistance is making it so I can keep designing in meantime.  I am currently thinking to just use PSOS on all finds but it depends upon startup speeds for PSOS.

Link to comment
Share on other sites

"Can I make my opening script see if it is PSOS and not go through all the bells and whistles I have in startup?"

​It is FileMaker. You're the developer. What do you WANT to happen?

 

Your OnFirst Window Open script will run.

You can detect whether the script is being run by the server by putting this statement right at the head of the startup script:

If [ patternCount( get( applicationVersion); "server" ) ]

  Exit Script[]

Else

  Regular startup stuff

End IF

 

There is a difference between a scheduled server script and PSOS.

 

A scheduled server script is 100% independent of the logged in user.

You must specify the account name and password when setting up the schedule.

 

A PSOS script is being done by THE CURRENTLY LOGGED IN USER.

PSOS does not re-login.

​It is true that it does not know anything about the user's globals, found set, etc.

But it WILL inherently be controlled by and use all privilege set limitations of the user who issued the PSOS script.

FileMaker Server knows who is connected. It knows who "knocked" (who issued PSOS)

Link to comment
Share on other sites

Thank you Bruce.  This question is not about scheduled script.  On PSOS is it not true that it must run OnFirstWindow again?  I cannot find it now but I was sure I heard that from some podcast.  If not true and I completely misunderstood then I feel much better.

 

I shall add this test to the beginning of my start script.  I have saved an example of how to test for everything else already and that was the piece I was missing there.

Link to comment
Share on other sites

I don't understand why you are asking the question when it was all answered very specifically in my previous reply.

What do you mean by "testing for everything"?

Link to comment
Share on other sites

I have opening script to test the platform.  I know whether Mac or Windows or iPad.  I did not know how to test for PSOS being the one opening and you provided it.

 

"answered very specifically".  I am not sure why your response did not feel good but it did not.  To my friends, it would appear you have tone.  I work very hard to understand, study and apply everything someone says and your response was brash.  I do not need tone.  I know how to read and apply what I read very well thank you.

Link to comment
Share on other sites

Now I suppose I sounded with tone in response and for that I apologise.  You do not know what people do with what you give them.  You do not know that they appreciate it and most really need the help and work very hard.  So if we do not understand something please remember it does not mean we are stupid or being disrespectful.  It can mean that we did not understand and it can also mean that you did not understand that we understood which is this case.

 

You took your time and helped me so again thank you.

Edited by Charity
Link to comment
Share on other sites

Calculations are always based on a TOs context but that has nothing to do with security.

 

If you want to prevent the user from seeing certain records in a table, you set that up in the privilege set and that one is based on the actual table, not on any TO.

 

Still unable to test server stuff but I am trying to set up the security anyway.  So if privilege set is called Parts Clerks then I can trust restricting records to PARTS table in security with calc with something like Parts::NotPosted = 1.  And that would work nicely because it is a stored value in the table I am protecting.

 

But if I put $$CanChangePart = 1 then that would be bad because it would force all records to download first.  Same with global field or unstored calculation as PartsPricing::Price > 0 and Parts::NotPosted = 1 because it holds a related value so is not indexed.  Does it sound like I am getting it?

 

I am getting anxious to begin trying to serve up things and see how it acts.  I have commandeered a few friends to log in when ready.  Playing with myself is no fun!!

Oh.  And it does not matter AT ALL which table occurrence name I use in the security calculation, right?  It could be:  Parts or PartsReceived or AllParts etc.

Link to comment
Share on other sites

This topic is 3708 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.