Permission based portal display of menus

[hillborne]

I'm coming back to FMP after a long absence so please consider me a newbie.

What I want to do is create a menu system that is based on a User so that at the top of each layout are MENU and submenu options depending on whether the User has permission to see them. After clicking on a menu, the menu name gets passed as a script parameter to a Navigation script I have that works and takes the user to another layout.

Attached in 'A' is an example of what I want it to look like assuming the User had full access--2 horizontally oriented portals set to display 1-1, 2-2, etc... I understand that the menu positions and maximums are going to be fixed (7 Main, 8 Sub)

Looking at 'B'

I know I need a User table and I believe I need a pink Menu table listing all the 50 menu options with perhaps an attribute field to denote Menu or Submenu status.

I'm a little fuzzy about how Menu will relate to Submenu. Do I need a join table between them? Perhaps a self join? Note: Submenu options will be unique to the Main menu they spawn from. In 'A,' QUOTES will only ever appear under PRODUCTS. It seems like the submenu portal will have to be filtered by setting a global to be whatever main menu was chosen, right?

Ideally, I'd open up Bob's User record and put checkboxes next to all the menus and submenus he's allowed to access. I'm unsure about how to actually setup the relationship between the User and Menus. In the green join table called Menu Access? So from the user table there is a portal into Menu Access...or into Menu? The user interface for this is a little confusing.

Finally, it seems that this whole blue Menu Group will have to be attached to each and every other base table in order for the menus to show up? I'm making this anchor-buoy style so it's not a big deal but if you have any suggestions for simplifying this I'm all ears. This will be served via IWP.

If it's easier to send an example file I'll gladly learn from that as well. Also, if you are willing to accept a paypal re-imbursement for your time on this and possibly future questions, please send me an email.

Thanks!

Travis

[hillborne]

Hmmm....is something like this even possible? How about practical?

After seeing this link I have my doubts: http://filemakertoday.com/com/showthread.php?t=19229

Any suggestions for easy permission based navigation? Related value lists in drop down menus? How about a separate navigation table that pops up?

[comment]

It's certainly possible - whether it's practical is debatable. There's also the question of how bad it will look in IWP.

Note that this needs to be tied to privilege sets, not to individual users, and backed up by real security measures. How many different privilege sets do you intend to have?

[hillborne]

Hi Comment,

Thanks for replying. Understood about the security. I was reading another post about ersatz permissions and how they aren't as secure as the built in privileges in FMP.

There might be half a dozen companies with 1-3 levels of use...so about 20 sets.

Horizontal portals seem to be fine in IWP...what other issues were you thinking about regarding viewing it on the web?

If you have any suggestions on a central, easily replicated navigation method I'm interested in your...comments!

[comment]

Why would each company need their own privilege sets?

[hillborne]

There are several companies that would access the database on shared projects and I need a way to let company A see a portion of company B's records but not company C's. In addition, certain employees of each company would only be able to do and see certain records of the different companies.

[comment]

I am not sure how you intend to handle that - perhaps when you do, it will turn out that the entire menu thing can be a by-product.

That aside, you seem to be on the right track here: as you say, you will need a relationship to your mini-TOG from every other table - or at least from every other TOG. This can be based on an unstored calculation field = Get (PrivilegeSetName) or = Get (AccountName).

You don't neccessarily need a join table to establish menu items visibility; you could use a checkbox to assign each menu item to a privilege set/account. And, if you prefer, you can put all the menu items in a single table, with a self-join separating parent and child items (you will still need to attach 2 TO's, though, since you need two portals).

Another option is to use nested tab control objects to show/hide the menu items - but you might have too many possible combinations for this to be practical.

Edited February 4, 2009 by Guest

[hillborne]

The nested tab control object was my first thought I wasn't sure if you could show or hide the tabs depending on the privilege settings. I want to avoid giving the user error messages when they try to do things they aren't allowed to do.

Can you give me your opinion on using this portal navigation system integrated into each layout versus a separate Navigation window that pops up and then disappears after the user makes a choice?

What about having the pop up navigation be a hierarchical portal? I saw that and it looked pretty cool but it might be out of my grasp for technical reasons.

Also, if anyone were willing to send me a simple example file with any working method showing 2 accounts/privileges (Admin account showing all menus and another showing half the menus) plus 2 Main menus + 2 submenu examples, I will send you an Andrew Jackson via Paypal.

I'm crunched for time and need to get a prototype working and populated in the next 10 days.

Thanks for your help and consideration!

Edited February 4, 2009 by Guest
hierarchical portals?

[comment]

You cannot make tab panels show or hide depending on privilege set directly - but when the navigation is scripted, it's easy to add that part.

Can you give me your opinion on using this portal navigation system integrated into each layout versus a separate Navigation window that pops up and then disappears after the user makes a choice?

I don't think you have the option of a separate window in IWP. If your users are primarily web-based, I would seriously consider CWP.

You may find this thread interesting, too:

http://fmforums.com/forum/showtopic.php?tid/197408/

[Fenton]

Another way to think of this, rather than as "menu" access, is as "record" access. From what you say, you may have fairly granular access restrictions, ie., a certain person can see only certain records of some table(s). So I think of it more as a relational question.

If each company and/or employees only have access to certain records, then you need join tables where the company and/or employee IDs are entered, as well as the ID of whatever records, they can access. By "records", I mean the highest level of access. So, if Company A can see all of Company B's records, at any level, there would be, in a "Company_to_Company Access" join table, a record:

From:

Company A's ID

To:

Company B's ID

I used "From" and "To" as the fields, since it might only go one way. A checkbox could say whether this was true, and calculation fields for the IDs in that case, so it would only work 1 way. Or possibly 2 records if it worked both ways. I'm not sure which would be best, but seems doable.

If only some employees of Company A can see all of Company B's records, then there would NOT be a record in the "Company_to_Company" table for this, but there would be one or more in a "Employee_to_Company Access" join table.

If only certain Projects, then you would have records in join tables for that. So on for every level and objects in the database.

Navigation would at least start from the Employee's own record. Employees would have record-level access restriction of View permission to only their own employee record. It may end there, navigation and operations controlled by portals, using the above IDs (the Employee having both a CompanyID and an EmployeeID).

BTW, this same "ID based relational" system would also have to work the other way. In other words, on a particular Project record, you would use the join table back to Employees to see who could see/edit this project. This would be used also in "record-level" access restrictions in Accounts & Privileges. That would both protect access, and make Finds (if View restrictions) limited to appropriate records; you would disable/modify any "Find All" buttons. It would be slow, as View restrictions add high overhead to Finds, but safe.

Because you may only attach an employee to one particular project (or other level) of a company, you need to still see that they have at least some access to that company, for the company to appear in that top-level portal on their Employee record.

To do that you would have direct relationships to all the level join tables from the Employee record, and use the List() function to gather the CompanyIDs for that employee from all of them, return separated. So, even if they only have 1 join to that CompanyID, it will be in the combined list, and allow the company to show in their "Companies" portal.

So, you would show their allowed Companies in the 1st portal, a choice setting a Company ID global field, to populate the available Projects in the next, etc.. This successive portals choices is a fairly common technique.

I haven't done such a complex solution as outlined above, but I've used similar at a simpler level for navigation and access, and it worked.

[hillborne]

Fenton, Comment,

I truly appreciate your input and responses on this. In general, I'm unclear when to use a User table and when to rely on the accounts/privilege options.

Comment:

Regarding the pop up window--creating a new window, naming it, and selecting it are allowable script steps in IWP so if on every layout, I had an icon to bring up the Navigation window, I can show the user through filtered portals where he could go, right?

How do you feel about a pop up Navigation window in general? It would save me from having to copy/paste/re-context every current and future layout. The amount of mouse clicks are the same.

I am still considering how and if to use the accordion and the nesting/hierarchical techniques for navigation versus 2 filtered portals.

I still trying to piece together filtered portals, User table + privileges, as well as a navigation script in order to have a solid system that is both client and IWP friendly.

Fenton:

Whoah...okay...well I will start off slowly on a project by project basis and after the high level users get accustomed, I will ease into a more granular access.

You mentioned you have a simpler navigation and access system and I'm so curious to see it! Your theoretical construction seem great to me but I learn best by playing with things. Having too many large, abstract, and unfamiliar elements rattling around my skull leaves me in a spotlight deer trance.

[comment]

creating a new window, naming it, and selecting it are allowable script steps in IWP

True, but AFAIK (I have very little experience with IWP) there will be no real new window popping up - you will simply be moved to another layout.

However, an arrangement of 'do something, come back to a home page' would certainly be easier to create and manage.

[Fenton]

"I'm unclear when to use a User table and when to rely on the accounts/privilege options."

These tend to work together, for slightly different purposes, tho there is some overlap when you are using record-level View restrictions, as Finds are automatically limited to only records you have permission to see.

Accounts & Privileges are more about what you CAN see and edit, whereas the relational system is more about how you get to what you can see and edit. The User table has one critical purpose that both need. Which is that somehow you will have to specify, in FileMaker data fields, who can see what. The originating place where you will have an Account Name is in the User table. At that point it can be exchanged for the primary ID of the user table, if you want to keep the account name hidden from view in the other tables.

The relational system is needed for Accounts & Privileges. Because to establish what a person can see you are going to have to create a calculation which specifies which. I cannot see any way to do that other than using data tables which hold the user account or ID, which can be evaluated from where the user is to where the user wants to go.

In other words, you cannot create the Privileges until you have a relational system to evaluate them. Since it is a relational system, it lends itself to portals for navigation. Which both shows a person what they can see and gives them a way to choose records. You could alternatively use the same system to show or hide "menus," since anything in a portal only shows if the relationship is valid. Lay them out horizontally, like you said, with no line. Levels without access will not show.

Because all (or almost all) the relationships for access are many-to-many, they would be done with join tables. Each data table with restrictions would need the appropriate join table attached, to evaluate for the record-level access in Privilege Sets.

Such a system would lend itself to a centralized control center, based on the User table, with systems of portals, showing either records or menus. There would not be much need to ever leave, as all the other data could be visible in the portals, even down to the detail level. It would be one heck of a table occurrence group (TOG) however. You could jump out of it for such things as reports. Though just how you'd do that in IWP is questionable (by me anyway). Basically, you can show more records in a portal in IWP than you can in a list view (at least last time I looked).

The main difference between this "access levels" and other normal relationship systems is that you will likely want to bring in the upper level if a child is chosen. Normally one would choose the parent first, then the child. But since we are using each level for opening access, we would not want to do that.

In other words, if a person has access to certain records, say Projects of a Company, but not all for that company, then you would NOT want an entry for that person in the Person_to_Company join table, but only in the Person_to_Project join table. This is different from a normal structure.

You would however, want to show that they has SOME access to the Company. That could be done by gathering ALL possible access IDs into their User record. The List() function comes to mind as the method, by looking at all the join tables from the User table. So each of the join tables would need to be directly attached to User, as well as the normal hierarchal structure of chained tables.

If you built a simple example file with some of your objects, and a few sample records, IDs, etc., I may have time to add some of this. I don't really have time right now to do that myself.

Personally I have to say that this is not a beginner's project, not by any means. Nor do I think there is any ways to do this; though there could be tricks I don't yet see. But you are asking the right questions.

[hillborne]

Hi Fenton,

Once again, thank you for your time! I am sincerely appreciative of the effort this forum, and you in particular, expend in sharing knowledge.

I 100% agree that the scope of this project is beyond my abilities at this point so I am re-adjusting it as I go. I am starting with the ability to just filter the central portal navigation table based on the user or privilege set and will worry about the cross company access later. I can make do with reporting the data to the necessary people myself because anything is better than a flat file excel doc with 50,000 cells (including images) which is what I'm currently using.

I went to your website and see that you are a consultant. Is this still the case? It seems like you are busy at the moment but hopefully not too busy to entertain a business proposal? If you are interested, I'd like to see about an arrangement for consulting. Please contact me at travis at g mail if you are free.