Permissions + Filters bug in 3.60

Ok, here is a situation. I suppose that everybody can generate this error, bug, whatever. You have a table (in example, Employee) and have a permission filters for users on a field in this table. You have a form and source of that form is Employee table. In a form SourceTableView you have key, order and table filter (crucial for this test) set. Delete zup file (to ensure clean start). Login as first user that has permission filter on table. Open this form. Close Navision Do not touch zup file. Login as another user that has permission filter on same table but with different value. Try to open same form. It cracks, saying, You have no permission to read table, bla bla… Is this a bug or i missed something in properties? I tried to change SourceTablePlacement to any non-default value but it doesn’t work. It works properly if you don’t have a filter in a SourceTableView (then, filter must be set through c/al).

now, i have found that this potentially bug can be worked around by setting SaveTableView to non-default value “No”

Can you please explain what the “bug” is? From your descriptoion it seems to be working perfectly, that you do not have permission to acces the record you are attempting to read. I can not see why you would think this to be a bug?

That’s why we should all just move to Windows Logins. [8D] The ZUP file is the same for both Users logging in with different Database Users. If the user with broader permissions has left the form on a record not available for the rectricted user, well, too bad. I wouldn’t call it a bug, it’s “by design”.

I can’t even read in this post what it is that this phenomenon thinks is a bug.

Now that’s another funny statement, David. Your new comedian career will most certainly shoot to the top if you keep it up! [:p]

[;)] but seriously folks … what does this person think is the bug? That the user does nto have acess to a record that they should not have access to. OR maybe the fact that Navision is CORRECTLY remembering to go to the last opened record? Where is the bug [?]

Am I the only one that hates it when a newbie comes in, starts a thread that is going to create heated discussion, then vanishes. Please you out ther enew to the site. We do want to help you, but if you post a topoic, then vanish, how can we. There is more information needed to resolve your issue. But understnad that for us (me at least), I don’t like replying to topics, only to find that the original poster is just not interested.

Hello David and others… David; I understand your frustration, so I take up the role of the vanished “phenomenon” for a while. Because I agree with “phenomenon” that the program behaviour is a little rude. I’ll give you a better example, to prove my point: Suppose you set a filter on “Sell-to Customer No.” in the Sales Order form. Then this sales order gets deleted in the normal order processing. Next time I open the Sales Order form, I can’t, if there isn’t any orders with the same “Sell-to Customer No.”. I, the ordinary user can’t continue work, but a specialist need to be consulted to delete the sup-file or recompile the object. Why can’t the bloody form open in “blank” mode, with no record found, and let me remove the (silly, I know) filter? //Pelle Edit: The example seems to be wrong, but this kind of things happen. //P

OK, now I understand the issue [V] Yes it is bloody annoying. But it is correct behavior. Many forms were modified in veriosn 2.60 and on to have a SETRANGE(“No.”); in the on getrec trigger, which helped a lot. BTW the issue you describe, I agree is a valid problem. The issue that phenomenen was describing was a bug in security. Which it is not.

first of all: “i am sorry for my ‘vanishing’… problem is that i was involved in numerous of jobs and thing and was not able to see answers…” second thing: I do know that if I set permission on record, They are really applied in full! Thanx to Palle, who understood what I wanted to say and made an easy-to-understand example. Do you ppl think that this is a bug or what? It happens to me that two persons with different MBS Navision login (same Windows account though) works on same machine. What happend? They were asking admins oftenly to “correct an error”. There are still lot of clients that are not too educated for windows/navision work.

Firstly you obviously need to do more training for these people. But now that we finally now what your actual issue is, its pretty easy to fix. In your situation what you are supposed to do, is to create TWO SEPERATE shortcuts to Navision. They will be identical, except for the property ID=Username The command line inthe short cust will look like C:\prog…\Fin.exe ID=UserName in each shortcut, of course you will put a diferent name for username. This will allow each user to store their ZUP settings in a diferent file, and thus they will not mess each other up. Just for reference, its much easier if you explain what you are trying to achieve, then you can get solutions that will help you get there. I hope this is waht you are actually after. [8D]

It would be general solution for my problem. I found simpliest solution only for few people where this situation happened (and will, in a future) with SaveTableView = FALSE on few forms that permission filters are applied on source tables. Anyway, thx to everybody.

Why not just give them each a different desktop Icon?