I thought I had reported this before, but can’t find that post. Now on b32, and Find still fails when in User mode.
Click the visible/total box in the tool bar, select Find, and I can then do a search based on any fields I like. In Admin mode.
Switch into User mode, and when selecting Find, I get:
getfieldproperties( error: not authorized.
In addition, after this error occurs, I open the Help, and cannot type into the Help search box at the top. Also, Cmd-F no longer does anything.
I can’t find it either, but I do remember your post, and it was pretty recent.
Anyway, I have re-opened this issue in the bug tracker.
Got another error in user mode, this time trying to use the Text Import wizard. I assume it’s related to this general user-authorization problem. This occurred when she tried to drag a column from the top area into the bottom area:
dbinfo(“field count”) is not authorized.
My user (in User mode) reported that she cannot Delete a record. Is this due to the same bug?
So far, they cannot use Find, cannot use the text import wizard, and cannot delete a record.
Will these all be fixed in the next release, and can we expect it soon?
Thanks, --dave
Tokyodave,
If there is only one record in the database, you will not be able to delete it because the database cannot be completely empty. I’m not saying that’s your user’s situation. I’m saying that’s one situation where the inability to Delete a record is valid.
Something I should have pointed out back when this thread was first pointed out, there is not really such a thing as “User Mode” in Panorama X. I think what you mean is that you have locked the database to the account, set the Can Modify Design and Can Use Standard UI commands to Administrator, and then given the database to someone that was logged in with the user password.
When I do that, I cannot duplicate your most recent bug report. I have absolutely no problem deleting any record. Perhaps you have added a .DeleteRecord procedure to the database that is blocking deletion.
Today I am re-reading your original report more carefully, and I see that there is a bug, but it’s not what you think. You have disabled the users ability to use Panorama’s standard user interface in this database. This means that they can only use the user interface that you have created for them, they cannot use Panorama’s standard user interface. You’ll notice that most of the menus have been removed from the menu bar – it’s up to you to provide ALL user interface for this database. The bug is that though the menus have been removed, there is a “back door” way to trigger the Find/Select dialog, using either the toolbar or pressing Command-F. That is the bug and these back doors need to be removed. The find/select dialog is part of Panorama’s standard user interface, which you have disabled, but Panorama is still mistakenly allowing this dialog to open.
The Text Import window is also part of standard user interface, so it is also disabled. This is by design. The Import and Export menu items have been correctly removed from the File menu.
Note that the Can Use Standard UI setting is a security feature. Turning off standard UI allows you to control every aspect of the database. For example, you could hide certain fields in the data sheet and not allow the user to show them, or even not allow the data sheet to open at all. This allows you to completely hide the identity of your database fields, which means that even with a procedure no one but you will be able to access those fields. Imagine that a hacker gets hold of your database – even if they have Panorama coding skills they won’t be able to access the data inside except through the user interface they provide (unless of course they have somehow gotten your admin password). Standard user interface features like Find/Select, Text Import and Text Export reveal the fields of your database. So they are not allowed. If needed, you’ll have to build your own versions of these features that reveal only as much or as little as you want. Of course, that’s a lot of work on your part. Most users don’t turn off the Can Use Standard UI setting, because it’s just too much work and they don’t need that level of security. But it is available for you if you need it.
I suspect that what you really want is to restrict the ability to modify the database design, but still allow the standard UI to be used.
In this mode you still have the ability to customize the UI, for example you can fully customize the menus, but you can use the standard UI where needed.
Tonight I removed these “back doors” so that it’s no longer possible to open the Find/Select dialog when the user doesn’t have access to the standard Panorama user interface.
I did go one step further however, I also fixed the problems (yes, there were more than one) that prevented this dialog from working when the user can’t use standard UI. Why bother when now they can’t ever open this dialog? Well, they can, if you put the findselectdialog statement in one of your procedures. So if you don’t care if the user can see what the fields are, you can quite easily still use this dialog.
Because they are implemented as separate databases and not as dialogs, I cannot do the same for the Text Import and Text Export windows. However, I really don’t think these make sense in this situation anyway. The entire point of the option to disable standard UI is to lock things down so that the structure of the database is invisible to the user, and they can ONLY perform the actions that you can set up for them. This is for users that you don’t trust to properly use Panorama’s power and flexibility. In that situation, you should be setting up pre-configured import and export options.
If you do trust the user with power and flexibility, but you don’t want to allow them to modify your database design or code, there is an option for that (Can Modify Design). It sounds like that might really be the option you actually want to use.
