unrelated table data within a portal

[MacSig]

Hello guys,

I'm trying to implement a navigation bar based on the user's privilege set.

I have a table called navigation where I have 3 fields: button_name, privilege_set current_privilege_set (a calculation field equal to the user's privilege set). I have created an other instance of the same table called current_navigation and I have set up the relationship between the two tables (navigation.current_privilege_set = current_navigation.privilege_set).

Now I would like to place in each of my layouts a portal to display the available navigation options. I have tested it using a dummy layout and it works but here come my issue: is it possible to show within a portal data from unrelated tables?

Basically current_navigation doesn't have any relationship with my other tables (documents, rooms, locations). And if there is an other way to achieve my goal I don't want to create meaningless relationship between current_navigation and all my other tables.

If with a portal I can't achieve my goal can I handle it in some other way?

Thanks and have a nice day !

[normanicus]

I think if you look at posts under the 'Separation Model' section you might find out how to do this.

[MacSig]

Thanks for your reply.

I'm looking at the posts under the Separation Model section but I can't find what I need.

Can anyone point me at the right post?

Thanks

[Lee Smith]

Whoa, lets not jump into he Separation Model development yet.

Lets see if we understand what you want first.

I think your Subject is misleading a bit, because you have to have a Relationship in order to show the related data in a Portal.

I think what you are asking, and correct me if I'm wrong, is that you want to show multiple files (TOs) in the same portal. If so, the answer is no. However, you can create more than one Portal on a Layout to reflect other related data for the same Current Record. AND you can show Related Data Fields, without a portal, using a relationship.

HTH

Lee

[MacSig]

Hi Lee, thanks for your reply.

I think you didn't understand what I'm trying to achieve so let me explain it once again (I hope this time in a clearer way).

I have a solution with 3 tables (documents, rooms, locations). They have their relationship and everything looks fine.

Now I want to add a navigation bar according to the user's Privilege Set. I have 2 sets: User and Manager. For instance User can not create a new document record.

In order to achieve that I have added a table (dev_navigation) with the name of the button to insert within the portal, the privilege set and an unstored calculation field called currentPrivilegeSet that get (PrivilegeSetName). The table looks like:

button | privilege |

-----------------------

document list | User |

document list | Manager |

new document | Manager |

Finally I have created an other instance of the same table called CurrentPrivilegeSets related to PrivilegeSets through PrivilegeSets.currentPrivilegeSet = CurrentPrivilegeSets.privilege

In this way CurrentPrivilegeSets contains only the available options for the current user. For instance when a Manger logs in he can see docuemnt list and new document however when a User logs in he can see only document list.

I have create a dummy layout that shows records from CurrentPrivilegeSets with a portal and everything works fine but it is quite useless. I want to insert a portal within all my layouts that shows exactly the same options. The problem is CurrentPrivilegeSets currently is not related to any of my "business" tables (documents, rooms, locations) so I'm looking for a way to display in a layout a portal that contains data coming from an unrelated table.

I don't know so much about separation model but it sounds a good pick.

I hope this time the picture is more clear.

Thanks again and have a nice day.

[Fenton]

1. The general answer is, No, you cannot show fields other than global fields without a relationship.

2. Is the target field of the relationship stored? Because a relationship cannot target an unstored field, unless it uses the Cartesian operator (X), which is all matches, regardless of the fields or values of the keys.

2.a. If the target field is stored, it would need to be a privilege set name, as text. It would be possible to have records in a table with values of layout names, etc., which could be used for navigation, with a common privilege set name as the key field. However, there are bound to be many places where everyone could go. Hence you'd want a mechanism in the relational keys to target those as "all" (or similar).

3. Basically, what are you trying to do? I have almost never seen such a structure as above; though some very advanced "interface file for separation model" may have this (which is what norminicus was likely referring to). It may be that what you're doing makes perfect sense. It may also be that there are other ways to do it.

3.a. There is a method, called the "visibility" method, to hide or show buttons under certain conditions. Usually used to hide "admin" or "manager" level buttons from the "user" level, etc..

3.b. Another common technique is to fork scripts, based on privilege set, so that managers go to one layout, and users go to another, without either seeing the mechanism.

[MacSig]

HI Fenton, thanks for your explanation.

Basically I'm working on a database that will be published through IWP (I forgot to mention that earlier) so I'm looking for a web-compatible solution to implement some kind of authorization system: showing only the available options for the current user.

The "visibility" method could be a good option if it is web-compatible. I will take a look of that.

The first idea was to create different layouts for different privilege sets and redirect to the right one through a startup script but I prefer to implement a solution without redundant layouts.

[Fenton]

Took so long to post, that I missed yours. I would say that if you want to use this method of a "privileges" table, that you're going to have to attach it to every table where you want to test against it. Another option would be to create a relational value list using it. Then you'd only need 1 instance of the table. Because a value list has the option "Starting from:", and an unstored calculation field, using Get ( PrivilegeSetName ) is going to be same no matter where you are within one file.

So, either multiple instances, which is simpler, or a single instance, which is a little more complex to set up, and to test against.

I think most of use just do these tests directly in the script itself.

If [ Get ( PrivilegeSetName ) = "[Full Access]" or Get ( PrivilegeSetName ) = "Admin" or Get ( PrivilegeSetName ) = "Manager" ]

   Do something

End If

[i almost always test from the TOP of the privilege sets, because it is safer. You often add lower level privilege sets. If you test against those, and miss one (it happens), then those people will be able to do things you do not want them to.]

And also, put the restrictions into Accounts & Privileges itself. Otherwise you are not really "stopping" them, just discouraging them. There are ways to get around unless it is truly restricted. You are really doing the layout techniques as a courtesy, so they don't get errors for things they cannot do.

Edited December 15, 2008 by Guest

[Fenton]

I'm pretty sure the Visibility trick works in IWP, as it's a relational technique, a portal which either has or does not have a match. It might flash a bit. Which is why you should make its background the same as the layout it is on.

The general principle is a relationship (usually self-relationship), based on a conditional "flag" field (result number), to a "constant" field (often a calculation, = 1; I usually name it "z_c1").

z_cAdmin_flag =

Get ( PrivilegeSetName ) = "[Full Access]" or Get ( PrivilegeSetName ) = "Admin" or Get ( PrivilegeSetName ) = "Manager"

A relationship, "table name_self_cAdmin"

z_cAdmin_flag =:z_c1

A portal based on the above, with a button in it, will either show the button (which runs a script), or show nothing (it will still show the "hand", if you've chosen that option, but it will not run the script).

[MacSig]

Hi Felton, thanks for your replies.

Definitely I will put restrictions on the privilege sets.

About the "visibility" method, I'm sorry but I don't understand how it works.

z_c1 is the constant flag just to extract the values that match

and z_self_cAdmin contains if the current privilege set is "admin" (or wahtever) but where do I have to put them? On each table?

Do you know where I can see (or download) a sample?

Thank you for your help. I appreciate it.

Have a good evening.

[MacSig]

Please, can anyone let me know how I can make it works.

Thank you for any help.

[Fenton]

This is where it all came from:

http://www.databasepros.com/FMPro?-DB=resources.fp5&-lay=cgi&-format=list.html&-FIND=+&resource_id=DBPros000743

[Fenton]

Here is a small example

Admin_visibility.fp7.zip

[MacSig]

Thanks Fenton for the example. I appreciate it.

I have just a question for you: let us say in my solution I have 3 tables and 3 layouts (1 for each table). In order to make it works on all my layout I have to add to each table the 2 fields and to create for each table a self-relationship. Is this correct? Or is there a easiest way?

Thanks again for your time and have a nice day.