Craftercms - Social: Is it possible to specify which user attributes the "create comment" API should retrieve? - crafter-cms

Is there a way to specify which user attributes are retrieved in the response of the "create comment" API call?
I mean:
"user":{
"attributes":{
}
}
The call I am talking about is documented here:
https://docs.craftercms.org/en/3.0/developers/projects/social/api/v3/ugc/comments/create.html

There is a way to set a system wide way to control the profile properties returned for every API:
Edit $TOMCAT_HOME/shared/classes/crafter/social/extension/server-config.properties
Add studio.social.system.profileAgg.attributesToReturn=displayName,avatarLink,socialContexts,notificationLocale,autoWatch,defaultFrequency,isAlwaysAnonymous,ADD_HERE_ANY_EXTRA_ATTRIBUTES
Restart the server.

Related

docuSign - envelopeViews : createRecipient

ERROR: Content Type specified is not supported.
Hi there, I am new to DocuSign and I am trying to learn the implementation from last couple of days. What I did so far is, created a developer account and created a QuickStart project.
Goal
I want to integrate the DocuSign API's in my application, but I don't really want the user to leave my application. I just want to make use of DocuSign within my app. - Embedded Signing
What I did?
I successfully created an envelope with a sample document and after that I have to get that URL to view (for Recipient).
So I called the below API:
** EnvelopeViews: createRecipient**
** POST - {{baseUrl}}/v2.1/accounts/{{accountId}}/envelopes/{{envelopeId}}/views/recipient**
All the details, like accountId, envelopeId are correct, along with that the request body that I pass with this is:
Request Body
{
"authenticationMethod": "none",
"clientUserId": "bcc49234-f30b-XXXX-XXXX-XXXXXXXXXXXX",
"email": "abc#gmail.com",
"recipientId": "007",
"returnUrl":"http://localhost",
"userName": "user name"
}
Note: * clientUserId is my Integration Key (please let me know if this is what I need to pass here or something else).*
Response
{
"errorCode": "INVALID_CONTENT_TYPE",
"message": "Content Type specified is not supported."
}
Note: Apart from the solution, please provide any link(s) to resources where I can easily see the implementation(as in my use case).
Umair,
First clientUserId is a bit of a confusing term, it's not the IK (Integration Key) but any string you want. It is unique to the signer and the envelope. You choose it.
You can find a detailed example of this with code in 8 languages on the DocuSign Developer Center How To Request Signature Through your app page.
I'm not clear how you make the API calls, if you are using postman, there are headers that needs to be set. One of them is called Content-Type and it has to be set to text/plain.

What does it mean "Another object with the same value for property proxyAddresses already exists" during licensing an user in Azure AD?

I'm using the Microsoft Graph API versin 1.0 to update a batch of user and for some I receive the following error message:
Another object with the same value for property proxyAddresses already exists.
This happens with some few user, but not with many others.
However I don't understand what it means and how to workaround it.
Any ideas?
Update1:
This my the JSON payload sent with the request:
{
"addLicenses":[
{
"disabledPlans": [
"76846ad7-7776-4c40-a281-a386362dd1b9",
"54fc630f-5a40-48ee-8965-af0503c1386e",
"c68f8d98-5534-41c8-bf36-22fa496fa792",
"8c7d2df8-86f0-4902-b2ed-a0458298f3b3",
"9e700747-8b1d-45e5-ab8d-ef187ceec156",
"c87f142c-d1e9-4363-8630-aaea9c4d9ae5",
"b8afc642-032e-4de5-8c0a-507a7bba7e5d",
"2078e8df-cff6-4290-98cb-5408261a760a"
],
"skuId":"94763226-9b3c-4e75-a931-5c89701abe66"
}],
"removeLicenses":[]
}
Based on the error message, the property proxyAddresses should be unique.
Please make sure you don't configure the same proxyAddresses for multiple users when updating users.
In theory, this property cannot be updated through the Microsoft Graph API. So if you didn't put proxyAddresses in the body, please share the requests of the updated users which have this issue.
this may be old, I encountered a similar issue. I am doing a graph api call which indirectly updates some of user attributes, so getting this error. The tenant admin should check for duplicate records and remove or update them, they can follow this link

docusign api - ACCOUNT LACKS PERMISSIONS exception when creating an enveloppe with display or signerMustAcknowledge

I'm trying to create an envelope with a main document and several other supplementary ones via the REST API (on the POST /envelopes point).
Works fine except that i'd like to display some docs as supplementary one (asking for a view or view and accept)
Problem is that I cannot set the display / signerMustAcknowledge document property, got an ACCOUNT LACKS PERMISSIONS exception letting me know specifically that these 2 property are forbidden. Does anybody ever had such an issue ?
{
:status=>"sent",
:eventNotification=>{
:enveloppeEvents=>["Sent", "Delivered", "Completed", "Declined", "Voided"],
:url=>"http://requestb.in/16wh0yw1"},
:emailSubject=>"Sale pack",
:recipients=>
{
:signers=>[
{
:email=>"me#gmail.com",
:name=>"Nicolas",
:recipientId=>1,
:clientUserId=>1447,
:tabs=> {
:signHereTabs=>[{..., :required=>true}],
:dateSignedTabs=>[{..., :required=>true}],
:textTabs=>[{..., :required=>true}]
}
}
]
},
:documents=>
[{:name=>"doc 1",
:documentId=>1,
:fileExtention=>"pdf",
:documentBase64=> '...'
:includeInDownload => true,
:display => 'modal',
:signerMustAcknowledge => 'view'
}]
}
=> RestClient::BadRequest: {
"errorCode": "ACCOUNT_LACKS_PERMISSIONS",
"message": "This Account lacks sufficient permissions. Account does not have permission to set 'display' or 'signermustacknowledge' properties on document facture.pdf (Purchase)."
}
Thanks in advance ! Nicolas
EDiT : i'm using the legacy authentication with my integration account (within the request header ). Account is a demo one created a week ago, and request is post on /envelopes
At this time, Dec 22, 2016, the default permission set for new demo accounts does not include the Supplemental Documents feature.
Solution:
If you have a sales or technical contact at DocuSign, ask them to add the Allow Supplemental Documents permission to your demo account.
If you don't have such a contact, file a case with DocuSign support
I anticipate that the permission will be included with new demo accounts in the future, but we're not quite there yet.

Displaying additional profile fields that are synced with AD using JavaScript

Along with the thumbnail photo, I may want to display other properties in my master pages that are imported from AD such as "company" using User Profile sync
If I use SPServices.SPGetCurrentUser() (https://spservices.codeplex.com/documentation), I can get selected properties held in user profile settings. However, I can't make this call since the property does not exist here (yet).
var company = $().SPServices.SPGetCurrentUser({
fieldName: "Company",
debug: false
});
It is however, is displayed both in http://mysite.mydomain.com/_layouts/EditProfile.aspx when in Mysite and _layouts/ProfAdminEdit.aspx (Edit user properties in Central Admin). I guess my question is then to be able to use SPServices, do I somehow edit the default properties and include my "Company" attribute held in the user' mysite profile? Alternatively, is there another way to access the properties held in the user profile with JavaScript ?
Thanks
Daniel
$().SPServices.SPGetCurrentUser calls this page : http://you.site.com/_layouts/userdisp.aspx?Force=True&1376982818371. For me the function is not able to parse the page correctly, but you could simply use jQuery (or pure JS or whatever) to get by yourself the same page, and then parse it to find the data you want.
Otherwise you can use $SP().people() to query the User Profile Service and gets the info for the user. See the example from the provided link. In theory that should return you the same information or even more info.

Updating a wiki page with the REST API

How do you update a SharePoint 2013 wiki page using the REST API?
Three permutations:
Reading an existing page (content only)
Updating an existing page
Creating a new page
For reading an existing page, of course I can just to a "GET" of the correct URL, but this also brings down all the various decorations around the actual data on the wiki page-- rather than fish that out myself, it would be better if there was a way to just get the content if that is possible.
Are there special endpoints is the REST API that allow for any of these three operations on wiki pages?
As stated in GMasucci's post, there does not appear to be a clean or obvious way of instantiating pages through the REST API.
You can call the AddWikiPage method from the SOAP service at http://[site]/_vti_bin/Lists.asmx. This is an out of the box service that will be accessible unless it has been specifically locked down for whatever reason.
To read the content of a wiki page through the REST API, you can use the following endpoint:
https://[siteurl]/_vti_bin/client.svc/Web/GetFileByServerRelativeUrl('/page/to/wikipage.aspx')/ListItemAllFields
The content is contained within the WikiContent field. You may want to add a select to that URL and return it as JSON to reduce the amount of data getting passed over if that is a concern.
As for updating the content of an existing wiki page, it is not something I have tried but I would imagine it's just like populating another field through the REST API. This is how I would expect to do it:
Do a HTTP POST to the same endpoint as above
Use the following HTTP headers:
Cookie = "yourauthcookie"
Content-Type = "application/json;odata=verbose"
X-RequestDigest = "yourformdigest"
X-HTTP-Method, "MERGE"
If-Match = "etag value from entry node, returned from a GET to the above endpoint"
Post the following JSON body
{
"__metadata": { "type": "SP.Data.SitePagesItem" },
"WikiField" : "HTML entity coded wiki content goes here"
}
The interim answer I have found is to not utilise REST, as it appears to not be
fully documented
fully featured
supported across Sharepoint 2013 and On-line in the same way
So my current recommendation would be to utilise the SOAP services to achieve the same, as these are more documented and easily accessible.

Resources