Alfresco : searching filed which for specific Metadata field - lucene

In Alfresco we have the JSON representation of Metadata fields of a file. The following one is for an Image file:
{
"mimeType": "image/png",
"downloadUrl": "",
"content": {
"type": null,
"version": "",
"attributes": {
"resolutionUnit": "Inch",
"software": "Adobe Photoshop"
},
"newContentIconDuration": null,
"creationDate": "2016-08-03T14:58:32.656-04:00"
}
}
I am working on requirement to search all images files, which contains Metadata field "software": "Adobe Photoshop" (as we can see in above json structure).
By using the following code I can search all files in alfresco, which have 'mimeType' 'image/jpeg', but not sure how can I search for metadata "software": "Adobe Photoshop" ?
var docs = search.luceneSearch("#cm\\:content.mimetype:\"image/png\"");
Any suggestion please ?

I am able to get it now by using this statement :
var docs = search.luceneSearch("#exif\\:software:\"Adobe Photoshop\"");
Steps to get this field name is ==> go to Alfresco Admin Consile -> Node Browser
and put this value in PATH field with 'Nodref" selected : "workspace://SpacesStore/REFERENCEIDOFTHEFILE" . There we can see the Name of fields which is being used. Like in this case it is exif:software.

Related

Template message in whatsapp with static url

I am using whatsapp cloud api for messaging. I have created a template with a url button. In the template I have used a link to my app(Google play store). As per documentation,
https://developers.facebook.com/docs/whatsapp/on-premises/reference/messages#template-object
Developer provided suffix that will be appended to a previously created dynamic URL button.
I do not have any suffix as it is not a dynamic link. If I create a blank text parameter as sufix, Postman responds with error. How to create a url button without any suffix or please let me know if there is any other workaround for this issue. I do not want to add url directly into the body
{
"type": "button",
"sub_type": "url",
"index": "0",
"parameters": [
{
"type": "text",
"text": ""
}
]
}

Outlook 365 file attachment option auto-applies CSV column headers

I need to develop an integration using Mule which will create a *.csv file without headers, and email the file content as email attachment using Outlook 365.
Using DataWeave 2.0, I defined output application/csv header = false to create required CSV content without headers. Output of the DataWeave script is correct, which I checked in application logs and also by writing to local file system.
In the next step, I am passing this output payload to Outlook 365 using below code (MuleSoft Outlook 365 connector internally uses Outlook mail REST API - https://learn.microsoft.com/en-us/graph/api/resources/mail-api-overview?view=graph-rest-1.0):
%dw 2.0
import * from dw::core::Binaries
output application/json
---
{
"message": {
"subject": "Summary-" ++ now() as String {
"format": "yyyyMMdd"
},
"body": {
"contentType": "Text",
"content": "Please find attached summary"
},
"toRecipients": [{
"emailAddress": {
"address": p('outlook.toRecipients')
}
}],
"attachments": [{
"#odata.type": "#microsoft.graph.fileAttachment",
"name": "service-data.csv",
"contentType": "application/csv",
"contentBytes": toBase64(write(payload, "application/csv"))
}]
},
"saveToSentItems": "true"
}
Receiver of this email finds column headers created in the attached file, example:
column_0,column_1,column_2,column_3,column_4,column_5,column_6,column_7,column_8,column_9,column_10,column_11,column_12,column_13,column_14,column_15,column_16,column_17,column_18
,SDEN1001107GR,Dense 7.3N 100mm,Days,0,,Blank,,,,,,,,,,,,
I debugged this, and looks like Outlook 365 connector automatically adds column header 'column_X' if not defined. But, the requirement is not to include headers in the file attachment.
Could anybody please help how to ignore the column headers in email attachment?
Sample request payload:
[
{
"Code": "SDEN1001107GR",
"UnitUsagesUsage": "Days",
"Group": "Blank",
"Category": "A",
"Description": "Dense 100mm",
"Rate": "0"
}
]
The issue seems to be that DataWeave -not the connector- is receiving the header=false property as a reader property rather than a writer property. For example in the read() function or in the outputMimeType attribute of a source or operation. Reader properties apply to the input of the script.
You need to use as a writer property instead for the property to be applied to the output.
In the write() function you add writer properties as an additional parameter:
write(payload, "application/csv", {header: false})

Is it possible to read google sheets *metadata* only with API key?

It is possible to read data from a sheet only with API key (without OAuth 2.0), but it seems that reading the developer metadata requires OAuth 2.0.
Is there some way to read the metadata from an app without asking the user to connect his google account?
You want to retrieve the developer metadata of the Spreadsheet using the API key.
You have already been able to get values from Spreadsheet using the API key.
If my understanding is correct, how about this answer? Please think of this as just one of several possible answers.
Issue and workaround:
Unfortunately, "REST Resource: spreadsheets.developerMetadata" in Sheets API cannot be used with the API key. In this case, OAuth2 is required as mentioned in your question. The developer metadata can be also retrieved by the method of spreadsheets.get in Sheets API. The developer metadata can be retrieved by the API key. And in this method, all developer metadata is retrieved. So when you want to search the developer metadata, please search it from the retrieved all developer metadata.
IMPORTANT POINTS:
In this case, please set the visibility of developer metadata to DOCUMENT. By this, the developer metadata can be retrieved by the API key. If the visibility is PROJECT, it cannot be retrieved with the API key. Please be careful this.
When you want to retrieve the developer metadata with the API key, please publicly share the Spreadsheet. By this, it can be retrieved with the API key. Please be careful this.
Sample situation 1:
As a sample situation, it supposes that it creates new Spreadsheet, and create new developer metadata to the Spreadsheet as the key of "sampleKey" and value of "sampleValue".
In this case, the sample request body of spreadsheets.batchUpdate is as follows.
{
"requests": [
{
"createDeveloperMetadata": {
"developerMetadata": {
"location": {
"spreadsheet": true
},
"metadataKey": "sampleKey",
"metadataValue": "sampleValue",
"visibility": "DOCUMENT"
}
}
}
]
}
Sample curl command:
When you retrieve the developer metadata from above sample Spreadsheet, please use the following curl command.
curl "https://sheets.googleapis.com/v4/spreadsheets/### spreadsheetId ###?key=### your API key ###&fields=developerMetadata"
In this case, fields=developerMetadata is used to make it easier to see the response value. Of course, you can also use * as fields.
In this case, when above endpoint is put to the browser, you can see the retrieved value, because of GET method.
Result:
{
"developerMetadata": [
{
"metadataId": 123456789,
"metadataKey": "sampleKey",
"metadataValue": "sampleValue",
"location": {
"locationType": "SPREADSHEET",
"spreadsheet": true
},
"visibility": "DOCUMENT"
}
]
}
Sample situation 2:
As other situation, it supposes that it creates new Spreadsheet, and create new developer metadata to the 1st column (column "A") as the key of "sampleKey" and value of "sampleValue".
In this case, the sample request body is as follows.
{
"requests": [
{
"createDeveloperMetadata": {
"developerMetadata": {
"location": {
"dimensionRange": {
"sheetId": 0,
"startIndex": 0,
"endIndex": 1,
"dimension": "COLUMNS"
}
},
"metadataKey": "sampleKey",
"metadataValue": "sampleValue",
"visibility": "DOCUMENT"
}
}
}
]
}
Sample curl command:
When you retrieve the developer metadata from above sample Spreadsheet, please use the following curl command.
curl "https://sheets.googleapis.com/v4/spreadsheets/### spreadsheetId ###?key=### your API key ###&fields=sheets(data(columnMetadata(developerMetadata)))"
In this case, sheets(data(columnMetadata(developerMetadata))) is used to make it easier to see the response value. Of course, you can also use * as fields.
Result:
{
"sheets": [
{
"data": [
{
"columnMetadata": [
{
"developerMetadata": [
{
"metadataId": 123456789,
"metadataKey": "sampleKey",
"metadataValue": "sampleValue",
"location": {
"locationType": "COLUMN",
"dimensionRange": {
"dimension": "COLUMNS",
"startIndex": 0,
"endIndex": 1
}
},
"visibility": "DOCUMENT"
}
]
},
{},
,
,
]
}
]
}
]
}
References:
Method: spreadsheets.developerMetadata.get
DeveloperMetadataVisibility
If I misunderstood your question and this was not the direction you want, I apologize.

Google custom search api returns 0 results when searchType is image

I'm using Google Custom Search API to search for images. The search result is always 0 when I request for images. I'm following the documentation at the link below:
https://developers.google.com/custom-search/json-api/v1/reference/cse/list
according to the docs, by specifying searchType=images, the api only looks for images.
Here's what my url looks like:
https://www.googleapis.com/customsearch/v1?key=[API_Key]&cx=017576662512468239146:omuauf_lfve&searchType=image&q=cars
and the result looks like below:
{
"kind": "customsearch#search",
"url": {
"type": "application/json",
"template": "https://www.googleapis.com/customsearch/v1?q={searchTerms}&num={count?}&start={startIndex?}&lr={language?}&safe={safe?}&cx={cx?}&cref={cref?}&sort={sort?}&filter={filter?}&gl={gl?}&cr={cr?}&googlehost={googleHost?}&c2coff={disableCnTwTranslation?}&hq={hq?}&hl={hl?}&siteSearch={siteSearch?}&siteSearchFilter={siteSearchFilter?}&exactTerms={exactTerms?}&excludeTerms={excludeTerms?}&linkSite={linkSite?}&orTerms={orTerms?}&relatedSite={relatedSite?}&dateRestrict={dateRestrict?}&lowRange={lowRange?}&highRange={highRange?}&searchType={searchType}&fileType={fileType?}&rights={rights?}&imgSize={imgSize?}&imgType={imgType?}&imgColorType={imgColorType?}&imgDominantColor={imgDominantColor?}&alt=json"
},
"queries": {
"request": [
{
"title": "Google Custom Search - cars",
"totalResults": "0",
"searchTerms": "cars",
"count": 10,
"inputEncoding": "utf8",
"outputEncoding": "utf8",
"safe": "off",
"cx": "017576662512468239146:omuauf_lfve",
"searchType": "image"
}
]
},
"searchInformation": {
"searchTime": 0.049329,
"formattedSearchTime": "0.05",
"totalResults": "0",
"formattedTotalResults": "0"
}
}
If I remove searchType from the request, I get results back in the form of web pages. What is wrong here?
Your Custom Search Engine might have Image Search disabled. The CSE API returns 0 results if the searchType requested is disabled.
You can enable it by visiting https://cse.google.com/cse/all, opening your search engine, and switching the "Image Search" toggle to ON.
I'm 2 years delayed but i found the solution.
you need to go at your Custom Search Engine Dashboard and turn on the property "Search the entire Web" Or something like that.
When you get that property activated you must be able to see results

REST Media Type Proliferation

I took a look at this question that seeks to address the issue of REST media-type explosion. One of the suggestions was to have a media-type that describes a collection of anything. So for example, we could have an application/vnd.collection+json which is a collection with well-defined semantics that can hold a list of references to other resources:
{
"size": "3"
"elements": [
{ "href" : "http://my.api.com/resource/1" },
{ "href" : "http://my.api.com/resource/2" },
{ "href" : "http://my.api.com/resource/3" }
]
}
I know an option to alleviate chattiness is to include embedded representations of resources. How would a "generic" media-type for lists accomplish that? Don't the semantics of the list change based on which embedded resource is inside it? This is especially relevant if embedded resources have different processing-rules (which would ideally be conveyed by the media type). Would be alright in this case to allow in-band information that describes the media type of the embedded resource? For example we could have application/vnd.collection+json for both links and embedded resources that do something like this:
{
"size": "3"
"element-content-type": "application/vnd.link+json"
"elements": [
{ "href" : "http://my.api.com/resource/1" },
{ "href" : "http://my.api.com/resource/2" },
{ "href" : "http://my.api.com/resource/3" }
]
}
and if it contains an embedded resource:
{
"size": "3"
"element-content-type": "application/vnd.resource+json"
"elements": [
{
"id": "1"
"name": "Cool Resource"
},
{
"id": "2"
"name": "Awesome Resource"
},
{
"id": "3"
"name": "Super Awesome Resource"
}
]
}
The assumption is that application/vnd.link+json and application/vnd.resource+json have been documented as well.
I thought about this a little bit more, and I think it is actually OK to include the content-type like that. The reason is, we already do this. In HTML the script tag has a type attribute that can be application/javascript or application/vbscript (for example). The provides the browser a hint as to how to process the content of that tag. Similarly, I think the content-type in the above example achieves the same purpose: it tells the client how to process the elements in the collection.
I wanted to update this answer some more. It appears that another way to do this is to use a rel. At least, this is how HAL does it. You can create a namespaced rel with a curie so that you end up resolving the rel to a URL that points to documentation about that resource. This way you have access to the documentation and that should tell you all you need to know about the resource(s).