Hi everyone, 

first of all, I am a rookie and have limited knowledge. This is actually my first more complex db I have created or worked with.  

I have ammended a db from a lynda template which basically controlls shore excursions, booking and passenger activitiy records for river cruise ships. 

However, I work for various different companies on different vessels and everyone has partly the same and partly different shore excursions on offer with  different prices and details . Additionally every operator has some 10 - 15 different itineraries on offer, which are offered with different tour codes and dates.

With the high amount of vessels,  itneraries,  passengers,  different excursions and prices for each operator I want to create a priviledge set which, on opening only shows the records of a specific tour code and date and permanently ommits all other records during the user session. User X (which is the tour code) can only see any record with the tour code X. This procedure is not meant to be a protection but simply a functionlality. The Tour Code acts as a user name.

The db opens with the customer layout. As a signin page I still have to create,  would need two fields to filter records by user session. One for the tour code and one for the date as many trips are repeated during the season.

I have tried various privilege sets but seem to be unable to get it done right. Here attached, where I stand. I have tried many different options but the ones on the screen shots is the last, I have tried. I keep getting error messages (access denied) when I try the different options. 

Any help is highly appreciated

 

 

I don't understand the basic situation you describe. It seems this is a file for your own use only. Do you intend to log in as a different user every time you want to work with a different operator? Judging from what you say here:

2 hours ago, amerioca said:

As a signin page I still have to create,  would need two fields to filter records by user session. One for the tour code and one for the date

the answer is no. Otherwise you would have to create an account for each operator, and allow access to records when:

TourCode = Get (AccountName)

and there would be no need to enter the tour code at a "signin page". 

 

If you do want to select the operator after logging in, then make the condition:

TourCode = SomeTable::gTourCode

where gTourCode is a global field you would populate at the beginning of a session (and could change at any time afterwards, without having to re-log in under a different account). And in such case it makes no sense to name your only user account after one of the operators.

 

Note that allowing access to limited records does NOT "permanently ommits all other records during the user session". Unauthorized records will be automatically omitted from find results and ignored by relationships, but you can still access them - albeit without seeing the actual data - by showing all records, for example.

I forgot to add the most important point:

3 hours ago, amerioca said:

This procedure is not meant to be a protection but simply a functionlality.

Then a privilege set may not be the best tool to achieve such functionality. Perhaps all you need is a couple of filtered portals.

Tnx for your detailed replies and sorry for not being more clear. The db reflects all passenger activity such as passenger information, shore excursions, cabin no’s, cabin changes, charges, invoicing, arrival and departure list,  complaints etc etc.

During a cruise with a lot of passengers, there is a lot of searching, filtering and isolating records on an almost hourly base. Not all passengers go on every shore excursion, or change cabins or arrive/depart on the same vehicle or from the same departure point. The db is supposed to filter this information with detailed reports, for every activity of the current cruise (tour code). As a result I am getting detailed reports on every single shore excursion sales, capacity planning on shore vehicles cabin changes, charges etc. etc.  

But once finishing one search request, the very moment, a different passenger shows up with a different request, I have to go back to ‘show all records’ I will get all records from all cruises and all vessels from the past, which it is a lot of data and complicates every process significantly. I know that I could write a script with extended search and filter parameters but I would have to add that script to almost every single layout and constantly change the search parameters.

A filtered portal is also not an option, due to the enormous amount of data and reports for every single cruise

On opening I would require only records of passengers and shore excursions of the very Tour Code we are currently operating. Meaning, that I intent to permanently isolate all records from previous cruises and only see the ones of the current one for the entire session.

The filtering by date I require for the very reason, that one vessel sails the same itinerary various times per season with different passengers.

What would be the best way to achieve this?

The beauty of using a privilege set is that FM will automatically hide the data if you do a search etc and it makes certain that the user does not accidentally see the other data.

You say it is not a security issue per se but that depends on how important it is that they not accidentally see that other data.

Without using a privilege set you may have to go to great lengths to keep filtering data as users navigate, do searches,... perfectly doable, especially when using custom menus if the users are free to do their own non-scripted searches etc.

 

I think you need to start by locating the cruise you want to work with (as you intend to do anyway). Once you have done that, you can simply use the Go to Related Record[] script step to navigate to the other tables while showing only the relevant records.

You can also utilize the relationship to remove irrelevant records from value lists -  so for example you can select only from this cruise's passengers when populating a shore excursion (or vice versa). Although if you use a portal or a card window to select, then again a GTRR is all you need.

Another tool that you could utilize is script triggers; for example, you could use it to automatically constrain the found set after performing a find.

 

Anyway, if you prefer to use a privilege set, you can do so as described in my first answer.

 

Edited June 8, 20196 yr by comment

Tnx a lot, Comment. The trick with the script triggers worked just fine.