I have a Registration ContentType, which contains a ContentPicker field for a Building Item, which contains a Geolocation Part with some properties like Latitude and Longitude.
When a new Registration is Published, it triggers a custom Workflow that sends out an email. In the body of the email I can get to the fields of the Building using tokens like this: {Content.Fields.Registration.Building.Content.Fields.Building.Address}
How can I get to the property values of the Geolocation Part contained within the Building? Can I do something like this? {Content.Fields.Registration.Building.Content.Parts.Geolocation.Latitude}
I'm new to Orchard and I can't figure out how it's structured. Can this be done out of the box or will I have to write a custom token?
If you know which content item to take from the content picker field (for example if it always is only one), then the following might work:
{Content.Fields.Registration.Building.Content.Fields.Building.ContentItems[0].Geolocation.Latitude}
This is assuming your Building field is configured to pick content types with a Geolocation part
Related
I'm working with a client on obtaining Bills and Adjustments values through the Contract based web services. I understand that certain fields aren't available in the Default Endpoint, and have to be obtained through an extension.
I'm trying to add fields from the Bills and Adjustments' Applications tab, but I'm running into a warning that I don't understand. If I extend the Default endpoint for 'Bills' (call it 'BillExt'), and I try to add the Reference Number field from the 'Applications' tab/grid (or any other field from that grid) - I get the following warning (see screenshot below)...
Can someone explain what the issue is, and how I go about adding these fields from the 'Applictaions' tab/grid? I've added fields from the 'Approval Details' grid without this warning without a problem. Is this a warning I can disregard?
You are trying to add a field from another table/view that can return multiple rows for a single Bill.
The correct way to do this is by adding a separate collection on the object and map the view on that collection. e.g: Applications or Details collections here.
That collection will have the information for all records related to the header once you retrieve them using the ?$expand=Details on the query string request.
I'm trying to query for some SP list items, all is working fine except I can't seem to expand a custom column of type Person.
I can see the createdBy and lastModifiedBy expanded and even includes the AAD user id, which is great and also leads me to think what I want is possible!
But mine is a custom column.
I'm running this and can only seem to get the SP user list id and the user's display name...neither of which are much use.
/items?expand=fields(select=UserLookupId,User)
Ideally I'd like to get the AAD user id as per createdBy and modifiedBy field, but the email would suffice.
Otherwise the only way I can see is to query the User Information List (using the UserLookupId) to get the email?
Thanks
This appears to be correct assumption:
Otherwise the only way I can see is to query the User Information List
(using the UserLookupId) to get the email?
for non-system user fields, it is indeed a way to go, but there are some distinctions whether user field is multi-valued or single-valued.
If Approvers is a multi-valued user field, then the following query:
https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items?$expand=fields($select=Approvers)
returns email and id properties along with displayName property for user field value.
While for single-valued user field only id (available via {userfield}LookupId property) and displayName properties could be requested via items endpoint, for example:
https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items?$expand=fields($select=Approver,ApproverLookupId)
So, indeed User Information List needs to be utilized to request additional user properties, for example:
https://graph.microsoft.com/v1.0/sites/root/lists('User Information List')/items/{item-id}/?$expand=fields($select=Email)
where item-id corresponds to user field lookup id
This was my experience modifying the
Build Angular single-page apps with Microsoft Graph. In the examples below, I changed my id's out with the default text.
Here is
The Finished Project on thier github
In Graph Explorer, this worked. You can verify it at the Microsoft Graph Explorer.
https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items?expand=fields($select=id,Title)
In the app/graph.service.ts in the app, this did not work. Even though you would expect it to based on the graph explorer.
.api('/sites/{site-id}/lists/{list-id}/items?fields($select=id,Title)')
Changing the app/graph.service.ts api call worked.
.api('/sites/{site-id}/lists/{list-id}/items?')
.expand('fields($select=id,Title)')
The result looked like this:
fields: {
#odata.etag: ""d6f5b6ea-9f90-452d-98ba-e838f58d3359,1"",
Title: "IT SPECIALIST (MID)",
id: "20"
}
Here's an example site id:
some.sharepoint.com,9dk062b-2e54-4e4f-b71a-cdb74f42cc44,c6cf6b0a-cc7c-41fd-a76a-ef8f97e8a22f
Here's an example list id.
8eg8c29a-5555-4cfc-bfa4-0e907488f781
The end url won't have any {} in it.
Can I add hidden metadata on the document level like you can through the API? In the DocuSign API, I can do the following in the document object:
new Document()
{
DocumentId = (i+1).ToString(),
DocumentBase64 = Convert.ToBase64String(request.Documents[i].Stream.ReadAsBytes()),
Name = request.Documents[i].Name,
DocumentFields = new List<NameValue>()
{
new NameValue()
{
Name = "DocumentType",
Value = "ElectronicConsent"
}
}
};
The DocumentFields specifies what that document is. Through the API, I can retrieve the document and its field:
EnvelopeDocumentsResult docList = envApi.ListDocuments(_accountId, envelopeId);
DocumentFieldsInformation docInfo = envApi.ListDocumentFields(_accountId, envelopeId, document.DocumentId);
Since I know what the returned document is, I can now run business logic on it. I'd like to allow users the ability to perform a similar action in the UI. This would allow the API to retrieve an envelope that did not originate in code, but the code still knows how to handle that type of document.
I tried the following:
I created a "Document Custom Field."
The "Document Custom Field" is of type "Drop Down" and contains various known document types.
I modify the custom field so that it is white and read only (the signer won't be able to modify it).
Before sending the envelope/document, I add this custom field to the form and select the correct document type.
I send the document.
When I run the same API method to retrieve "Document Fields," the value doesn't get returned. It appears that manually placing the field on the document results in the field being part of the "form" instead of metadata.
You cannot set Document Field as you can set it in an API. The Document Custom Field which you are setting is just another reusable DocuSign tab. So on WEBApp if you are planning to use Document Custom Fields, then your Connect listener should check for two things, one document fields which will be coming from the API, and the Document Custom Field which will be coming as form data. When doing through WebApp, I will make that field white label on white text so that it is not visible to the customer, but it is present on the document. To make maintenance easier on your side, I would create two Connect listener, one just for API user who will be using Document Field, another for non-API/WebApp user who will be using these reusable Document Custom Fields, and write different logic on both listener.
Using the Docusign API, I am trying to change the fields that exist on a document. When I first create the document, I am able to change field values using "tabs." I get how to do that.
When I am trying to edit, or in Docusign's terms "correct," a document after it has been sent out, but before being signed, I am having trouble figuring out how to access those fields again to change the values.
I have tried using the API avenue described here ( PUT /v2/accounts/{accountId}/envelopes/{envelopeId}/documents/{documentId}/fields ), but even after successful calls, the values of the fields aren't changing, and I believe it is because I should be trying to access the tabs, as I did when first changing the tab values as I created the document, instead of targeting the fields, since the two seem to be different. Any thoughts? Thank you in advance for your answers.
To update Tab values you should use the putRecipientTabs api.
Once a signer completes the Signing process, the tab values cannot be updated.
Also not all Tab values can be updated. See this answer for more information.
The putEnvelopeDocumentFields api is for a different purpose. Document fields are different from Tabs. Document fields are an array of name-value custom data strings to be added to a document. Custom document field information is returned in the status, but otherwise is not used by DocuSign.
I figured it out.
The "fields" we are seeing on documents are "tabs," and they are children of the recipients.
The hierarchy goes envelope > recipients > tabs, which tabs we were trying to change. Not envelope > document > fields, which refers to something else--just familiarizing with the language of the api.
Here is a link to the reference for how to change "fields" aka "tabs", and that link includes sample requests.
One thing that helped me target my actual fields, since I kept on getting an error that the field didn't exist for the recipient, is to do a get request of all available tabs and use that response body as the request body for the update call (where we change the field values). Then you know the field information will be accurate, paring the body down to exactly the "fields" aka "tabs" you are interested in targeting.
I cave created a custom list in sharepoint (created and provisioned to the 12 hive)
how can i perform validation on certain fields of the list when a new list item is added?
i think i can do it through the "itemadding" event reciever, but is there a more elegant sharepoint way?
eg i just want to check an email field has a valid email format.
I think you have to options. As you have already mentioned using a event receiver would be one way. But I think a more elegant and above all a more SharePoint like way would be implementing your own custom field type and field control.
This will give you the option to validate the mail address before any event receiver is triggered and to react with an validation message to the user giving him the option to correct his input.
You could go with validation on the client using JQuery if you have the id or a css class on the rendered textbox for the email input.