network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 9 months |
| seen | Mar 21 at 21:48 | |
| stats | profile views | 3 |
|
Feb 20 |
awarded | Supporter |
|
Feb 20 |
accepted | Getting TermSet and Terms from Microsoft.Sharepoint.Client.Field |
|
Feb 20 |
comment |
Getting TermSet and Terms from Microsoft.Sharepoint.Client.Field Thanks for the answer, it did point me in the right direction! Microsoft.SharePoint.Client.Field does not have any "SspId" property BUT I finally found it in the "SchemaXml" property along with the TermSetId. With those I can now get the "TermStore -> TermSet -> Term -> Label" structure I need. Just a bit of code to do and I think I should be good! Thanks again |
|
Feb 20 |
asked | Getting TermSet and Terms from Microsoft.Sharepoint.Client.Field |
|
Jan 7 |
answered | SPUtility.GetPrincipalsInGroup not working when claims authentication is enabled |
|
Jan 4 |
revised |
SPUtility.GetPrincipalsInGroup not working with every AD Group deleted 241 characters in body |
|
Jan 3 |
accepted | pickerentity.key with Claims |
|
Jan 3 |
answered | pickerentity.key with Claims |
|
Jan 1 |
awarded | Student |
|
Dec 31 |
revised |
pickerentity.key with Claims added 288 characters in body |
|
Dec 31 |
asked | pickerentity.key with Claims |
|
Dec 6 |
awarded | Editor |
|
Dec 6 |
revised |
SPUtility.GetPrincipalsInGroup not working with every AD Group added 605 characters in body |
|
Dec 6 |
comment |
SPUtility.GetPrincipalsInGroup not working with every AD Group I also thought that could be it but I looked in our active directory and "Domain Users" is a Security-group with a global scope which works just fine with any AD group that I would create manually. "Domain Users" does contain all users that were created on the domain so I really don't get why SPUtility.GetPrincipalsInGroup returns 0 users. |
|
Dec 6 |
asked | SPUtility.GetPrincipalsInGroup not working with every AD Group |
|
Nov 29 |
comment |
web.config entries not deleted when deactivating farm feature Thanks a lot for the answer! I've had a look at the application that I wished to uninstall programmatically and I finally found out that the problem was that it used SPContext in order to delete those specific web.config modification. So when my external application tried to deactivate the feature, SPContext was null so that part of the code didn't execute at all. I don't have enough rep to upvote your answer but thanks a lot anyways. |
|
Nov 29 |
accepted | web.config entries not deleted when deactivating farm feature |
|
Nov 23 |
asked | web.config entries not deleted when deactivating farm feature |
|
Aug 24 |
accepted | Upload document : Default value not applied on choice column if baseFieldControl.ControlMode = SPControlMode.Display |
|
Aug 22 |
comment |
Upload document : Default value not applied on choice column if baseFieldControl.ControlMode = SPControlMode.Display I finally found a way to do it in ItemUpdating that I think wont screw the way things work when simply editing a document's properties. Here is what I did : SPListItem spListItem = properties.ListItem;
foreach (SPField field in spListItem.Fields)
{
if (field.Type == SPFieldType.Choice && field.DefaultValue != null)
{
properties.AfterProperties[field.InternalName] =
properties.BeforeProperties[field.InternalName] ?? field.DefaultValue;
}
}
I still have a lot of testing to do as there are many cases that will run through this code, but I believe I am on the right track now. |
