Which of these should I use? When is it appropriate to use SPUtility.ResolvePrincipal() (MSDN) instead of SPUtility.ResolveWindowsPrincipal() (MSDN)? (The MSDN Documentation is not helpful in the least).
Looking at the source code through reflector it seems like
SPUtility.ResolveWindowsPrincipal only tries to resolve Windows user accounts or Groups.
SPUtility.ResolvePrincipal tries to resolve both: Windows User accounts and group as well as Sharepoint Users and Groups.
Related
How does one use vba to share an excel file with another office user? I have a template that needs to be customized slightly and shared as a separate workbook with hundreds of users (same active directory).
I have a table mapping out what files should be shared with what users as shown here:
I thought I could use a sharing method to set the permissions using MSOPermission. I've tried quite a few approaches which have all failed, but these were the ones I was most optimistic would work:
wkBk.Permission.Add "bill_User#company.com",msoPermissionEdit
wkBk.Permission.Add "SallyCEO#company.com",msoPermissionRead
wkBk.Permission.Add "billy_companyID",msoPermissionEdit
The specific error I receive (shown here) indicates something is wrong with the Permission Object. I can't find much documentation on this (a common pet-peeve of mine with Microsoft).
I've seen a couple posts shown below, but none address my question.
Automate File sharing
Share and unshare file
Permission sharing
I'm sure I'm in the wrong area or maybe I need to enable a library. I'm embarrassed to say that I even attempted to use the macro recorder, but no code was logged when I interacted with the sharing menu shown here.
Bonus Question
It's possible that VBA is not the best tool for handling my use-case situation. If there's a better automation method for my situation such as TypeScript or Power Apps, I will upvote any suggestions that include basic instructions or a reference with specific terms/procedures that I could use to hunt down an overall solution. Thanks.
Note to Microsoft: Executing this comparable task in Google Sheets is easy and well documented:
ss.addEditor("billyTheUser#gmail.com");
ss.addViewer("sallyCEO#gmail.com");
PowerApps was mentioned - assuming you have a standard O365 license and SharePoint Online available then it's possible to set access as needed here's an illustration from an SPO Documents library file:
Microsoft Documentation:
https://support.microsoft.com/en-us/office/customize-permissions-for-a-sharepoint-list-or-library-02d770f3-59eb-4910-a608-5f84cc297782
Option 4 from this article:
https://sharepointmaven.com/6-locations-can-set-security-files-sharepoint-office-365/
We're running Jira 7.7.0 and Confluence 6.0.4
Our team is split into 2nd level support and 3rd level (us).
PROBLEM:
We would like to let 2nd level to do as much admin support as possible with as few permissions as needed.
1. The software offers for Core two admin groups, but both offer too many admin rights (Jira Administrators / Jira System Administrators)
2. Confluence has 2 groups Admins and users
DETAIL:
None of the global permissions of either permit, that we allow a group to
- Add Spaces
- Add projects
- Add users
- Add groups
but keep them otherwise out of all the rest
DESIRED
A way to have a super user be able to not just manage >existing<, but also add the entities mentioned above.
OPTIONS?
A) A plugin that enhances users to be "a bit" Administrator, BUT with ADDING feature (this does not seem to exists)
B) A plugin that hides the menu items, but would technically still enable the users to execute the tasks if a URL was known
QUESTION
- Does anyone have a hint on what plugin could manage this? Either permission or menu hiding?
- Is there a way to trick configuration to achieve this (I assume not)
Many thanks!
Carsten
There is an addon called Delegated Project Creator for Jira that address your request. To get it, search for it in the marketplace under "administration".
On the other hand you can tweak the UI of both apps to control access to options using Jquery. The addon Script Runner for JIRA has some options for this.
We used to have a plugin in LR6 that used a specific user group, which also had the administrator role assigned to it, for several use cases.
However, when trying to replicate its logic on LR7, this plugin correctly imported the users from a remote data source and put the users into this group. I can see their profile, which seems to be exactly what we need: in the "Inherited Regular Roles" the Administrator role is present.
However, they cannot see the control panel.
In an experiment, I administratively created a user group and assigned the Administrator role to the group. same behavior here, they cannot see anything.
I am poking around the source code, and it seems some parts of the module do use:
PortalPermissionUtil.contains(
permissionChecker, ActionKeys.VIEW_CONTROL_PANEL)
Which seems to verify inherited roles... Am I missing anything?
Bottom line, it seems that I cannot create usergroups of administrators anymore.
It turns out, yes I was missing something: a bug
https://issues.liferay.com/browse/LPS-61319
So, this will be an issue till GA4 at least.
I'm using liferay-portal-6.2-ce-ga5 in which some functionality like assigning a site to a new user or giving to use social office etc. So we can see here admin is assigning a site so what I want that it should be done automatically or any code so that it can be achieved?
If you're doing it to everybody (e.g. every new user should be member of a specific site or have the same role, like "Social Office User"): Go to "ControlPanel / Configuration / Portal Settings / Users / Default User Associations" and configure as you like.
If this is not what you're asking for, please rephrase your question to be more specific.
For programmatically achieving this, you'll find a bunch of sample code in James Falkner's blog article on the ancient sevencogs code.
On the "My site" feature of Sharepoint there is a "memberships" Web part that shows the distribution list that the user is a member of.
This is picking up several groups that we would rather not be shown e.g. some that have been set up for administrative purposes only.
Is there any way to control which groups are shown; ideally this would be using another AD group and setting that only members of this group are shown.
I'm fairly sure this won't be possible without a custom web part that is deployed instead of the official part. The reason the Exchange solution doesn't work is because it's going the wrong way (from group to member instead of member to group).
To deploy it you can look at feature stapling... you would need to update the existing sites as well.
This is not an easy answer. I don't believe there is an easy answer.
The best solution would be to set a Deny Access Right for the distribution lists in Active Directory; follow these steps:
1) Open Active Directory Users & Computers as an admin (any user with access to creating groups and modify distribution list security settings).
2) Go to the View menu and make sure that there's a check-box next to Advanced Features.
Create a new security group in Active Directory (call it HideFromSharePoint or something) and add the SharePoint Content Access account (in my case DOMAIN\sa_spcontent) to that group (has to match the account used in step 4).
3) For all of the distribution lists that you don't want to show up in SharePoint do the following:
3a) Open the distribution list and select the Security tab (Advanced Features must be checked for this tab to be shown).
3b) Click on Add and type in the name of the security group that you created in step 3 (HideFromSharePoint); click Check Names and click Ok.
3c) Under Permissions for HideFromSharePoint; check the Deny box next to Read (it's set to Allow by default) and click Ok and Ok again at the prompt.
You've just denied any members of the HideFromSharePoint group read access to the distribution list.
4) Go to SharePoint Central Administration; SharedServices1; User Profiles and Properties; Configure Profile Import and under Specify Account enter the credentials of the account that you added to the HideFromSharePoint-group in step 3. (For some reason if you leave this to using the Default Content Access account SharePoint will use some other account to access Active Directory and thereby being allowed access to the distribution lists. You could experiment with adding other SharePoint service accounts to the HideFromSharePoint group but I think it's safer to specify an account explicitly so that you know which account is accessing AD and importing the data.) Also make sure the "Import Connection" for your Active Directory is set to "Use Default Account" (thereby "inheriting" the account used for Profile Imports).
5) Go to SharePoint Central Administration; SharedServices1; User Profiles and Properties and click on Start full import. (You can't do an incremental import because nothing has changed for the users in terms of group membership; it's just the access rights that have changed.) After completion of the full import (click Refresh until "Import time:" says "Started full import at 11/25/2009 ##:## AM - Ended import at 11/25/2009 ##:## AM")
The distribution lists should now no longer show up under Memberships.
A couple of things to note:
You have to set the Deny Access Right explicitly and individually on all of the distribution lists that you don't want showing up in SharePoint. That's because the special AD-group "Authenticated Users" has read access to every object in the directory by default and explicit Allow Access Rights trump Deny Access Rights set (for example) at the organizational unit level.
While you could skip the step of setting up the HideFromSharePoint-group and set the Deny Access Right directory for the SharePoint Content Access account Active Directory administration best practices is to use a group when configuring security permissions. (Then you can add additional members to that group and have those denied read access too.)
You might have to wait a while (5+ minutes or so) between setting the the Deny Access Rights for the changes to replicate to all of you domain controllers. Otherwise the import might read from a domain controller where the Deny hasn't yet come into effect.
Be careful adding any other accounts to the HideFromSharePoint-group because this might break your distribution lists. For example; if Exchange can't read the groups mail won't work. As long as you just add the SharePoint Content Access Account you're safe.
Also (and this has nothing to do with SharePoint or the solution above) be aware that any user in your domain can fire up ADUC or a LDAP tool and see the members of your distribution lists that way. If you have anything "Top Secret" you need to experiment further with setting access controls in Active Directory.
I assume that your "memberships" web part is using the SharePoint people picker functionality internally.
If that's the case, then the following stsadm command should help you scope your AD lookup the way you want it:
stsadm -o setsiteuseraccountdirectorypath -path <name of OU> -url <URL name>
You could try editing the Distribution List on the Exchange Advanced tab, selecting the "Hide group from Exchange Address lists" check box.
I have not tested this but in theory it would stop the Distribution List from appearing the the list of groups.
Easy fix: add a JavaScript to the page on which those appear that targets and then hides the specific items by applying a CSS style.
I don't have an exact answer, but here's how I would think through the problem. Perhaps you have already answered some of these questions, but it might help to go through them again. I would look at the questions in the following order:
Is there an option in Active Directory to hide a group from SharePoint? (sounds like no)
Is there an option in SharePoint administration (either through stsadm or the actual administration site) to exclude certain users or groups in AD from SharePoint?
Is there a way to configure the web part to exclude certain users or groups from the web part itself?
Is the source code to the web part available such that you can compile the web part to exclude certain groups in the list?
Can you use javascript (as Josh mentioned) in conjunction with the webpart to hide the Distribution Lists from the webpart? (Here's a site with an example of how to use JavaScript to Hide SharePoint's Quick-Launch bar. Maybe that will help).
Those questions are in order from the widest scope and easiest to implement to the narrowest scope that is more difficult to implement. Obviously, you'd like to implement a solution that is easiest to implement, but perhaps you find yourself farther down in the list.
In the last two examples, the solution may appear quite complex, but you may be able to write code that references an XML file of sites to exclude. That way, if your list of Distribution Lists changes, all you have to do is edit the XML file and not edit the source code (of either the javascript or the webpart).
If there's not a simple solution, you'd have to make the painful choice of either 1) letting the problem remain or 2) implementing a hack that adds a dependency to your solution.
I think Distribution Groups that aren't security enabled don't show up in SharePoint. Have you checked AD to see if these groups are security enabled? This may be only for permissions purposes, so I could be wrong.
You will probably need to do a profile import before you see any changes.
You can turn off Distribution Lists entirely, which is what we are doing at my company. This is done by going to the Profile Services Policies in the SSP and disabling the Distribution List feature.
Now if you want to pick and choose the Distribution Lists, it's not that simple, but hopefully this will help someone.