I have unprivileged user group in zabbix. I make read-only access to the one server group and I want to hide some Problems|issues for them.
On the dashboard page unprivileges user see all problems as I am, but I want to hide all low level problems (disk load, processor load, ...) and stay only some hi-level errors.
It's possible? All I've found is the limitation of the sending of notifications with media. But on the dashboard the problems are still displayed
You cannot do that with the current permission model - there is a feature request to improve it.
You can hide lower severities with a dashboard filter, though. As this isn't something editable from the UI, and you cannot set defaults for users, the best bet would be setting the desired filters for a single user, then copying the filter settings from that user to all other/new users on the database level. Note that users would still be free to change their filter settings afterwards, and they could see this information in all other screens.
Related
We work with a large Access database and we want a few users (max. 5 to 6 at the worst) to be able to edit tables at the same time by using forms. We have split the database into front end and back end. The BE is placed on a NAS and each user has an offline copy of the FE on his own desktop.
All users have full permissions and we switched the options (client settings -> Advanced) to the following settings:
Default open mode: Shared
Default record locking: Edited record
Open databases by using record-level locking: yes
Encryption method: use legacy encryption (good for multi-user databases).
In the forms we also changed the property ‘record locks’ to ‘edited record’.
What we want to achieve is that when a user change a certain record in a form, other users can’t change the same record until the changes of the first user are saved. We also want to see a lock icon in the selector bar, as mentioned in this forum:
Instantly "locking" a record in multi-user Access environment
For the moment we have done several tests, but we are unable to generate any “Writing conflict” when implementing the above, contrary to the numerous reports on the opposite behaviour one can find reported in the internet and the documentation of Access. The first user changes a record and the second user is still able to change it, without any particular notification in the sense of a selector bar icon or a “writing conflict”, and the user that closes the database the latest takes it all (all changes by the first user are overruled).
Can anyone explain me what we are doing wrong.
You have to set the locking on a form by form basis. So changing the client settings to "edited" record will ONLY become the default for new forms you create.
So, to set locking for a form to edited record, you MUST set EACH form you have to Edited record. Once you do this, then additional users attempting to edit the same reocrd will see + receive a lock icon in the selector bar. They only will see this bar WHEN they attempt to start editing, but if you set form to "edited" record, then this should work fine.
The "over all" settings you are playing with don't change anything here (well except the option to open databases as shared - but that's already the default and already a given since more then one user is able to edit the data.
So change the form in question locking setting to "edited" record. You now have record locking setup for that one form. Settings for record locking are a form by form setting - the other settings really don't matter.
I have an Access 2013 DB with 2 subforms: The first one provides current data and the second one I'm trying to set up as a sandbox space for users to make changes and updates at their leisure. When they are ready to submit those changes and updates they can hit submit and their results will update the current data and table info behind it.
Been a while since I've messed with Access so I can't recall if this can be done so thought I would ask.
It can’t be done without a rather messy approach. Forms in access ALWAYS edit ONE row.
What I do in these cases is allow the user to “edit” as much as they please.
However, say we are doing a “classic” check or donation amount enter. So you have a donation amount (say $50), but you THEN have to distributed the amounts to various donation accounts.
With the above, you don’t want to save the data until such time that the amounts distributed to accounts match the donation amount.
Because we can’t contain the form + sub form as a “single” update, then what I do is add a posting flag to the parent form (the one record in the main form).
The user can then edit/add, go away for coffee, and come back and edit some more. You can even come back the next day and continue editing.
Once the user is happy, then you have a post button on the form.
If the user hits post, and the balance amounts don’t match, then you don’t set the postOK flag = true.
The above will thus NOT provide a means for the user to bail out, or un-do their edits to the “whole thing”, but it does allow you to determine that the data entered has been “balanced” and verified. And if the “balance” did not occur, then you can skip that record, or introduce a process in which the data is not posted or marked as done until such time that the data balances.
Here is a screen shot in Access of a “classic” money distribution to several accounts. You can see the donation amount on the left side, and on the right side is the account distribution of that amount.
However, at the bottom of the screen, for the “job task” the user is working on also has a post button. When they hit the post button, if the amounts don’t balance out, then the posting is NOT yet done. In fact, I let the user enter "many" donations, and then they can "post" all at once for ease and speed of working. The "post" does NOT actually post, but checks the balance. So users "think" they are posting, but it only really ever sets one value (a flag POSTOK).
So to run a report, it can’t be run until such time that the post button was hit.
As noted, this approach will NOT give you a “bail out” option to exit your data entry, nor does it allow you to “undo” the data entry, but it DOES allow you to verify the posting is “ok”, and “valid”. In many cases this approach will suffice.
However, if you looking for some kind of “undo” for the form + sub form edit, then Access quite much is not the correct tool for that type of business model and edit.
I would suggest you set up a local temp table for the sandbox.
Then when you say 'When they are ready to submit those changes and updates they can hit submit and their results will update the current data and table info behind it.' ….. instead what happens is the Sandbox Temp table record appends or inserts/updates the actual table.
If this is a split multi user app and the Sandbox temp table is local - then the data is indeed temporary and the update must occur within the user's session. But the overall design is quite simple.
After finally getting back into this I realized I was looking at Access development through the eyes of how I would do it in Excel; both different ecosystems. I took off my Excel forms dev lens and a few things occurred to me that I think may help others with similar struggles:
Access and Excel are different VBA development ecosystems. You can’t necessarily code it in Excel and expect it to work flawlessly in Access.
A subform is just a form...and like all forms its controls, code, and behavior don’t change in functionality but in presentation based on form type (datasheet, continuous, etc).
Treat each Form and event code independently of each other. If your subform on a parent requires events to kick off when a user adds, updates, deletes, validates, etc. that code should belong in the form that makes up the subform.....not the parent.
The parent form should only control filtering and results from the subform as well as it’s own set of actions the user has.
The Screen method is amazing and one I think would have saved my life for tracking changes. Great link here: https://www.datawright.com.au/access_resources/tracking_data_changes_in_access.htm
Intent: I would like to distribute forms to User X, User Y and User Z. These forms would be pre-populated with existing data on their ongoing projects. Meaning for User X, he will only be able to see his own details etc. They are to validate the information, and make changes to the data if necessary.
I tried finding the best way to go about executing this and landed on MS Access (if there's something else, please do share).
So I have a database, created my forms but how do I go about sharing only the forms to my users and updating my database. Resources I have include:
SharePoint Online (may or may not have access to it...)
Outlook
Desktop Access
I am open to various scenarios involving direct updating through SharePoint, or even manually updating the forms received through them via email if it is possible.
My most important consideration is data security. User X should not be able to see the details of other users. User-level security from older versions of Access could probably do that but its no longer in the newer version and a check online suggests it isn't the most secure option.
Any help would be much appreciated.
You do not include any information on what kind of data your "forms" includes why you collect the data and what do you want to do with it. At the very least if data from multiple users needs to be combined for any sort of overall reporting.
If the most important consideration is limiting each user to a sub-set of the data then I don't see how you decided MS Access is your best option. Any security on an Access file is easily bypassed. On top of that unless each of your users has their own set of tables you cannot set up any kind of security that isolates their individual information.
To completely isolate user information you have three options:
Use a separate database for each. Then, if you need to, link them all
into a master database in the back end.
Use an isolated front end. You cannot use an Access front end as that
will have to link to the tables; you have to use a separate
interface, either a web type interface or a Windows application that
the user has to log on and has no access to any data other than what
the software is displaying.
Use import/export files. Have access export each user's info to an
Excel sheet or other convenient data file. Let them make their
changes and return the files to you, then import them back into your
database.
What is the best practice both security and performance focused to avoid letting users see incrementally IDed data in database or other dataset.
Main concern is to avoid urls such as
www.myweb.com/user/123
This of course applies to posts, users, files or messages.
Implement permissions so that only authorised people can see/change/delete data.
If you still want to hide the incremental ID from users or API consumers, you could add a hash column to your database and index it, then expose that instead of the incremental ID.
Hiding Incremental IDs
Depending on your programming language, the unique ID you assign your users may not need to be displayed in the URL. For example, with PHP, you can use the $_SESSION[] array to store values on your server for each user. Those variables will never be seen by the user, but the server will be able to identify each user appropriately (via PHP cookies) and serve them the correct page dynamically.
For example, when a user signs in to your site, after authenticating, your script might do something like:
$sql = 'SELECT id FROM user_table WHERE name = :username';
// Prepare & execute SQL query, putting result in $sqlResult
$_SESSION['user_id'] = $sqlResult;
Now, whenever the user wants to visit their own page, your server will know which information to fill your home page template with -- and the URL will appear the same to every user.
If a user wants to visit another user's page, you could do something similar: upon choosing a specific user page to visit, your script could set a $_SESSION['visit_user'] variable. Thus, you would be able to fill a visit page template with the appropriate information, and your user will be none the wiser.
This same tactic can be applied to posts, files, etc. that are assigned incremental IDs.
But Is This Necessary?
As you yourself mentioned in your previous post, there are plenty of examples of sites that use incremental IDs -- and with no qualms about displaying them. Because while this does give a malicious user the ability to view other users' IDs, etc., this doesn't necessarily pose a threat to your site's security. If you follow basic security principles (require strong passwords, watch your MySQL users' and files' permissions, sanitize user input, etc.), it doesn't matter if malicious users can guess at auto_incremented IDs. Those IDs aren't valuable information unless your site can be exploited in another manner.
I would appreciate if someone would help me with this.
I am new to Access and my boss has given me a project to create a tool for our team (I work in insurance). I'm done with most part of the project, but my boss wants editing and updating of database restricted to a few members of our team (yes more than one person can modify) but since the tool is to be used for a wide range of purposes, she would like that the rest of the department (50+ people) can only access certain forms which have buttons etc. that do the job.
So far in this database I have, 3 linked tables (which hold all the data), queries, reports, union queries and make tables and 3 forms. What I would like is for most people to only view forms and use it in form view only, but 4 members of my team to do whatever they want since they need to constantly edit the data.
Does anyone have a hint about where I should begin? Programming is not my cup of tea so I would really appreciate some reference etc. or any help!
If you hit file, then hit options, and then select current database, you can force a specific form to pop up whenever you open the access database. In addition, you can take away the user's ability to go through the entire database's content. you can also take away the navigation bar and menus and such. I have been doing this for a while, so here's some advice. Have a main menu form that has a button for every form in the access file. When the user opens the database, he or she should see that main menu form. From there, they can click on the button that will lead them to the form that will solve the needs they have.
Stackoverflow won't let me post a comment, so here is what I was going to say. For those who you want to have access to it, you can have them hold shift while opening the database. If they do that, they will open the database like they were an "admin" to the database. They would be able to edit it however they would like if they hold down shift.
I have done this via a table, assigning users a specific "Security Level" and checking their security level via a login screen. I then hide the login screen (not close it) so that anytime a form is open it can do a DLookup of the user's security level and then determine if the user has read, write or read/write access to the form. I can also hide buttons on the form based on the same logic.
Starting in 2007, Access removed their native security, which was pretty inefficient anyway.