|
| Button | Discussion | Instructions |
|---|---|---|
| Project | Project | Project |
| Databases | Databases | Add Databases
Configure Databases |
| Subsets | Subsets | Subsets |
| Search Categories | Search Categories | Search Categories |
| Stopwords | Stopwords | Stopwords |
| Users | User Administration | User Administration |
| Messages | Messages | Messages |
| Layouts | Layouts | Layouts |
Available in Release 2.0 and later.
Each Project has user who is designated the Project Owner. The Project Owner can add other users and allow them some or all administration permissions. Before you read further, please read this note about Data Security.
To see a list of users and their permissions, logon as the Project Owner and then click the Users button, then click the List of Users link. This is also a way to find someone's password if they have forgotten it -- hover the mouse pointer over the words (point here) in the list. For safety, passwords for Administrators are never shown.
To Add a user, return to the previous display and click the first radio button, then fill out all four boxes. The user ID must be unique within your system, but the user name need not be. Note that you assign passwords for new users, but they can change it to whatever they want later.
When you add a user, only the lowest level of permissions are given. The granting of other permissions is done as a second step.
To Change permissions for a user, click that radio button and then select the user from the dropdown. Click OK and you will see the user and all his/her permissions that you can change.
The Change User Permissions display varies depending on who is using it. For example, only an Administrator (the Project Owner or someone with equivalent privileges) will see the options to let others use IMS or to make other users Administrators. The user with permission to add/change/delete other users is NOT an Administrator and does not see these two items.
Here are the permissions you can set with this form. Some permissions are not yet functional in MWeb Universal, but you can assign them now in preparation for future releases. Or you may just ignore them. The inactive functions are shown in a gray font.
| Permission Level* | The user's View Permission, which must be 1 to 9, inclusive |
| Exempt from IP Restriction* | The user will be able to see IP-restricted data from outside the museum |
| May create Favorites** | User may make sets of Favorites. This permission is granted automatically to users who self-register, but not to users added by an Administrator. |
| May add/delete/change users | Allows this user to add or delete other users and grant certain permissions. This user will NOT be allowed to give other users permission to run IMS or to be Administrators. |
| May modify others' Favorites** | User can modify anyone's Favorites sets |
| May use IMS | User may run IMS. Be careful of granting this permission except to trusted users. |
| Make this user an Administrator (i.e. Project Owner) | Be VERY careful of granting this permission, as it gives this user full control over your MWeb system (equivalent to the Project Owner). Only one (or at most two) Administrators are required for a site; you can grant specific permissions without making someone an Administrator. |
* These items will have no effect until the MWeb Security Model is implemented in a future release
** These items will have no effect until the Favorites feature is implemented in a future release
To Delete a user, click that radio button and then select the user from the dropdown, then click OK.
Permissions are implemented using cookies. Cookies are shared by all browser windows. Therefore, if users' computers are available to others, please tell them to close ALL browser windows before walking away, to prevent the next user from using MWeb with their permissions. This is especially important for Administrators as anyone could view the list of passwords.
Please report any problems you find with MWeb so we can correct any programming or documentation errors. Here is the essential information we need to know to solve problems:
If we cannot recreate the problem at our office we cannot fix it. This means that email is the preferred medium for communicating problems, so you can write down the steps you use to produce the problem. Attaching a screenshot of the error message can save you time and help us.
MWeb Universal may be a bit slower than other search sites because it is requesting searches from multiple Databases. The results cannot be displayed until all Databases have responded. Although all Databases are searched at once, the system can only be as fast as the slowest Database in your Project.
Having numerous Databases on the same server can reduce performance because the server is having to respond to multiple queries at once. This will be slower than having the Databases on separate servers. We have noticed no performance problems with 17 Databases on the same server; with 34 Databases performance was noticeably worse.
For large Projects of more than 50 Databases you may wish to investigate our MWeb Enterprise product, which creates a single database from all sources; we would apply the cost of MWeb Universal to MWeb Enterprise should you choose to switch.
Another problem could be that your Relational Database does not have the correct indexes. For example, if a Full Record Query or Image Query are required, these mean that multiple tables must be joined, and the fields used for joining should be indexed for best performance.
All contents of website, including HTML and JavaScript, copyright © 1996-2010 Systems Planning. MWeb, InFORMer, and CAPS are trademarks of Selago Design, Inc. MARCView and MARConvert are trademarks of OCLC, Inc.
Systems Planning
Including the name of one of our products in the subject of your message will bypass all spam filters.