We have a set of log analytics workspaces, each with some workbooks. One workspace for each project. We need to grant the administrators access to the workbooks for general monitoring. I have assigned the as owner on the log analytics, but hey only see their own workbooks. They cannot see the one I created. When I read this article it states you need:
Global administrator
Security administrator
Security reader
Report reader
Application administrator
But I am sure I have misunderstood you need those privileges' to show workspaces to system administrators. Anyone know how to manage access for a single workspace and related workbooks?
https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/howto-use-azure-monitor-workbooks#prerequisites
where did you save your workbooks? when you saved, you would have picked sub+resource group. do those users have access to query resources in the sub+resource group you saved yours to?
the workspace RBAC controls access to the database itself, but where you save your resources (the workbooks) determines if other users can see them or not.
If you think of all this as a file system,
think of the workspace as a specific database file, "C:\rg1\workspace A\database.db"
subscription sub as a drive letter, "sub a" = "C:", "sub b" as "D:", etc
resource group as a folder inside a sub ("D:\rg2")
Just because you granted a user RBAC access to #1, doesn't mean they can see things you saved into #3.
by default when you save a workbook it would try to save it to the same sub+rg as the workspace itself, but depending on RBAC users might not be able to create resources there.
(with the analogy above, the default setting would be to try save new workbooks into "C:\rg1" where the workspace is, if you have write access on that RG)
Additionally, if you created your workbooks at some point in the past, you would have had the option to save them as "shared" or "private" (aka "my workbooks", which we're working on deprecating because this confuses everyone). Make sure you didn't save yours to "my workbooks", as only the author can see those. you'd have to use the "move to shared" command in the editing toolbar to make sure your workbooks are shared so the others can see them.
Related
I'm trying to figure out a way to allow users to save their view on the Tableau server. I have set allow access permissions for 'download and save option' to the group while publishing the report to a particular group of users.
Even though when they log in the only option available for them is 'Revert' and 'Done'.
I have tried given ALL permissions to the user with no luck what so ever...
What can the issue be then?
I, as the owner, can see the "Save" "Save As" buttons,
Any help is appreciated. Thanks much
Take a look at: http://onlinehelp.tableau.com/current/server/en-us/help.htm#web_author_who.htm
Specifically:
Download/Save As—determines whether the user sees the Save and Save As commands while they are editing a view, and whether they can save their changes to a new workbook. It also determines whether users can open a workbook on the server using Tableau Desktop.
To save changes to a workbook or save a workbook as a new workbook on Tableau Server, a user must have a site role of Publisher. The Save and Download/Save As capabilities must be set to Allow in the workbook permissions.
Also
Note: Users with a site role of Interactor are not allowed to save or download workbooks.
I have some issues with the Plone 4.3.1 permission settings. But I have come long way with the existing documentation and Aspelli's book. But I cannot figure out why I am unable to create any object in a folder, even as Site Administrator, after setting up a workflow-state that grants permissions to a specific user role.
The workflow-state is called "Show_External" and the permissions that are set through the Permissions tab of the workflow state are as follows:
Permission Acquire Site Admin Ext_Supplier
Access content information - X X
List folder contents - X X
Modify portal content - X X
View - X X
I do not want to "Acquire" any permissions because the new role is for an external supplier that has no business with anything else on this particular site.
The result - much against what I expected - is that no one can create any object. The option is shown in the interface, but any attempt results in Error Please correct the indicated errors.. No errors are indicated however.
What I can do is make the objects (folders and files) in another folder and then copy paste them to the folder that is set in the workflow-state. Stranger still, once I copy the folder as a subfolder to the External Supplier folder a can add files through QuickUpload, but not by selecting "Add file".
What am I missing in my understanding of the permissions?
You likely ran into a bug, which was fixed just now:
http://plone.293351.n2.nabble.com/Bug-on-sharing-page-upgrade-plone-app-workflow-to-2-1-6-td7566655.html
Does upgrading p.a.workflow help?
The solution in the end was to install plone.app.workflowmanager. For some reason that I do not understand the "Permission Roles" that show up under the workflow states created through ZMI did not have either the "Add" or the Review Permission.
Correcting the permissions through the workflow manager solved the problems.
If you try it out then note that you need to check the "Advanced Mode" checkbox to be able to update the permission settings on existing objects.
Having dregdged through ZMI screens for the past few days, the Workflow Manager is a great improvement! Very nicely done.
If someone can still explain why there is a difference between the permissions that I set through ZMI and the workflow manager I would very much like to know (feel free to edit this answer, marked as "community wiki").
When setting up local synchronization with a Sharepoint 2010 site using Sharepoint Workspace, where are the local files stored? More importantly, how can I change the storage location?
There is a folder-like object created under username\Workspaces, but when checking the path in the explorer address bar, it shows simply username\Workspaces, unlike other folders that show as C:\Users\username\xxxx. Right clicking the folder only provides the option to open in new window - it can't even be deleted! There are no options for setting storage location within the Workspace application itself.
Using an SSD system drive, I don't have the space to put all this data on C:. Only part of my user profile has been relocated to other drives, so the default for new items is still C:. Without a knowledge of the real path where this is stored, I can't even use junction points to redirect.
Much web searching has revealed nothing on this subject. Your help is appreciated.
the data is stored within the users profile. I don't think taht you're able to relocated the synched database. The synchronized data isn't encrypted or password protected. So you should consider to activate profile encryption within your organization.
In addition to the location you aren't able to activate any kind of OOB protection for the local SQL CE which is responsible for storing the synched data!
The default location is %localappdata%\Microsoft\Office\14.0\OfficeFileCache.
The files in this location don't look like the actual files, and contain a lot of metadata.
Per Microsoft KB 2020636, you can change the location of the OfficeFileCache by adding an Expandable String Value named OfficeCacheLocation to registry subkey HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Internet with the new path. (This key is for Office 2010 only.)
In my organization, we reviewed the option of using Workspace for making files available offline, but in the end opted for a third party SharePoint add-on.
Since all of out users have Outlook and use it on daily basis, it made sense to have an Outlook sidebar available with all the users' relevant files. It also can synchronize a SharePoint library or folder and makes its items available offline using Microsoft Outlook, so we opted to use it instead of the OOB feature, which was too limited and had various security problems.
Just came across this and I think this will do the trick: How to change the default location of the Office 2010 Document Cache (NB: I haven't actually done it myself yet).
I don't have enough "reputation" on this site to post additional links, but if you search on the following, you can find more background:
OfficeFileCache Folder Size 3-4x Larger than Actual Content (SharePoint Workspace 2010)
Sharepoint Workspace Fills Hard Drive – WTF?
I have a form that has a list box and several buttons that run sqk statements for the list box.
sub on_onClick()
' error checking
me.listbox.rowsource = "SELECT tblMain.First, tblMain.last FROM tblMain ORDER BY tblMain.Last;"
so this kinda thing is what I use for the list box. it works fine for me in the .mdb, and after i have converted the database, split it, made the .mde I go into the mde and it works fine for me still. This is placed on a shared drive
HOWEVER, anyone else that tries to use this, none of the buttons are having an effect. Can't tell if they are not working, or the VBA is not returning any results for them. It works for me, but it is not working for them. So...this is for my local LAN team, I think they all have full control permissions??? The button clicks that get them to that form are working fine also.
please help!
A couple of things come to mind:
It is not clear from your question whether the mde file itself is on a shared drive or whether the back-end database is on the shared drive and each user has a copy of the mde file on their PC. If the users are using the same mde file on the network share then I would strongly suggest not taking this approach. (It probably isn't the cause of the issue, but it will get you into trouble down the road.) Give each user a copy of the mde (front end) and have the application point to the back-end database on the network share.
Make sure that the mde has the ability to relink the tables to the back-end mdb file.If you search SO you'll probably find examples of how to do this in code.
I suspect you may be running into an issue where the mde file is not able to find the back-end tables. In this case you won't receive an error message in your VBA code when you're setting the listbox's rowsource and it will appear as though nothing is happening.
Do they have Macro security disabled? By default, MAcro security is enabled in Access and none of your VBA code will run. To disable: open Access, Tools -> Macro -> Security and set to low.
I think it is generally best to use self-certified projects or a secure location rather than change security levels.
Some information on macro security:
Self Certify projects
General information on security principals for Office code and macro security
Trusted location defaults for Office 2003
Macro security in Office 2003
I've been working on making my app easier to use for administrators. One of the things I'd really like to do is allow admins to modify other user's settings from within the program -- while still making it possible for regular ol' users to modify their own settings, as my application isn't necessarily only for administrators who want to force users to use specific settings.
I thought of two possible ways of doing this:
1) Move the user setting file path from where it is now (CLSID_APPDATA, commonly Documents and Settings\Username) to a world-accessible path (CLSID_COMMON_APPDATA , commonly Documents and Settings\All Users). Then, save each user's settings to a unique file for the user (probably having a name which equals that of the user's textual SID), so the folder looks something like:
C:\Documents and Settings\All Users\My Company\My Program\settings\123-abc-456-def.settings
C:\Documents and Settings\All Users\My Company\My Program\settings\234-bcd-477-xyz.settings
C:\Documents and Settings\All Users\My Company\My Program\settings\946-hdc-743-ddd.settings
Pros:This allows an admin to see and directly modify any user's settings, because the COMMON_APPDATA path is the same for all users. This is how I'd really like it to be -- it's the most straightforward -- but there's a major con:
Cons:Permissions could be a problem. To allow regular users to save their settings, you'd have to allow users write access to the program's COMMON_APPDATA setting folder.
Of course, when the settings are saved and the setting file created on disk, you'd want to limit write access on the user's setting file to the user who the settings are for, and for admins, so that other limited user's can't modify them.
However, it could be that before a user has a chance to write their own settings from within the program, a savvy, malicious limited user creates a setting file for that specific user, without the knowledge of the user. If the limited user creates the file, that means they own the file... and then that user (who the settings are for) can't modify the settings anymore, unless an admin changes the permissions on the file.
An unlikely situation perhaps, but it still worries me.
2) Instead of moving the setting file path to a globally-accessible path and modifying the user's setting file directly, have my app create and save an "override" file in the app's CLSID_COMMON_APPDATA folder, to allow the admin to override the user's settings.
When my app loads for that user (who's settings were "overridden") it'll detect this file and load it instead of the regular setting file, which is located in CLSID_APPDATA (Documents and Settings\Username).
Pros:Permissions are easy to deal with.
By default, for the Documents and Settings\Username APPDATA folder, only admins and Username can access the files from within. So that in itself protects the user's own regular personal settings from other limited users.
To protect the "override" settings, my app can simply deny write access to the COMMON_APPDATA folder -- where the override file is written -- to all but administrators, and then that's that. These overriding settings will only be modifiable by admins.
Cons:This method is obviously more roundabout. If a user modifies his own regular personal settings, an admin won't see those changes -- the admin can only see the settings he's overriding the user's regular settings with (which he can force the user to use instead).
In some ways, this might be good, but... the fact that it's roundabout turns me off somewhat.
I'm interested to hear what you guys think about this. Which is my best option? I'm personally leaning more towards #2, because while it's less straightforward, it seems to be more secure and isn't so roundabout where it'd be confusing for an admin.
However, I'm also open to suggestions. Is there a superior option you think would work better?
EDIT 7/6/09: I should note that for option #2, the admin could not only override all user's settings with a single override file, but also override an individual user's settings with an override file specific to that user (just like with option #1, that file name would likely be that of the SID of the user who's settings are being overridden). Not sure if that was completely clear in the original post.
Unless there is more than one user account on each computer (i.e. a computer is used by more than one person), option two is the better choice.
Even if there is more than one user account on each computer, I think option two is still a better choice. Worst case, the administrator will have to change settings on a handful of accounts on the same computer instead of one.
If your facility allows random usage of any computer by any person, then option one is the better choice, since option two will make it too difficult to maintain that many different accounts on every computer.
Of course, you can always put the application settings in user folders on the server. That would make it very convenient for an administrator.
If the administrator already has rights to the user's directory where his setting's file is stored, wouldn't that already solve your problem? Either way though, it sounds like option 2 would be best, then you could have a single file that could override say a group of users, then each user have their own settings as well. Just so long as your application is smart enough to tell when to override a setting and when not too, option 2 shouldn't be that much of an issue.