I can't seem to do this. The list that the app engine datastore viewer does not contain Text as an option. I had to change my fields because some of my values were too long for String, but now I can't retroactively fix my old entries.
To change the property type used by the old entities, you need to manually update each of them.
This can be easily and efficiently accomplished using the mapper API. This guide explains how to use this API.
You may also want to read this blog post by Nick Johnson.
You don't have to fix your old entries. The old ones should work as is, and the new ones just won't be indexed.
See
http://groups.google.com/group/google-appengine/browse_thread/thread/282dc825f9c46684 .
Related
As I am reading here, "when the imageAction is set to generateNormalizedImages, the new normalized_images field will contain an array of images. Each image is a complex type" which should contain a very important field for my scenario (rotationFromOriginal).
I noticed that, even if Azure Search perfectly accomplish the rotation of the images, this property will always be 0 (unlike other fields as originalWidth, which are correctly populated).
Do you know why I have this issue? Am I the only one?
AFAIK, the value of rotationFromOriginal was in normalized_images and it was as an input, so it must be populated at first.
And use the parameters in normalized_images json file to rotation and process image. For more details, you could refer to this article.
I am looking to create a feature whereby a User can download any available documents related to the item from a tab on the PDP.
So far I have created a custom record called Documentation (customrecord_documentation) containing the following fields:
Related item : custrecord_documentation_related_item
Type : custrecord_documentation_type
Document : custrecord_documentation_document
Description : custrecord_documentation_description
Related Item ID : custrecord_documentation_related_item_id
The functionality works fine on the backend of NetSuite where I can assign documents to an Inventory item. The stumbling block is trying to fetch the data to the front end of the SCA webstore.
Any help on the above would be much appreciated.
I've come at this a number of ways.
One way is to create a Suitelet that returns JSON of the document names and urls. The urls can be the real Netsuite urls or they can be the urls of your suitelet where you set up the suitelet to return the doc when accessed with action=doc&id=_docid_ query params.
Add a target <div id="relatedDocs"></div> to the item_details.tpl
In your ItemDetailsView's init_Plugins add
$.getJSON('app/site/hosting/scriptlet.nl...?action=availabledoc').
then(function(data){
var asHtml = format(data); //however you like
$("#relatedDocs").html(asHtml);
});
You can also go the whole module route. If you created a third party module DocsView then you would add DocsView as a child view to ItemDetailsView.
That's a little more involved so try the option above first to see if it fits your needs. The nice thing is you can just about ignore Backbone with this approach. You can make this a little more portable by using a service.ss instead of the suitelet. You can create your own ssp app for the function so you don't have to deal with SCAs url structure.
It's been a while, but you should be able to access the JSON data from within the related Backbone View class. From there, within the return context, output the value you're wanting to the PDP. Hopefully you're extending the original class and not overwriting / altering the core code :P.
The model associated with the PDP should hold all the JSON data you're looking for. Model.get('...') sort of syntax.
I'd recommend against Suitelets for this, as that's extra execution time, and is a bit slower.
I'm sure you know, but you need to set the documents to be available as public as well.
Hope this helps, thanks.
I am working on an extension to replace the select field type with radio/check boxes in Bolt cms. My problem is how to use bolt internals to store selected values.
Ajax POST data when I press save:
day[]: Monday
day[]: Friday
So this is the same as for select fields.
I followed this tutorial: https://docs.bolt.cm/extensions/customfields
and used
public function getStorageType(){
return 'text';
}
The response of the ajax-save request for this field is Array and this is what gets into the database. Interestingly select fields does not appear in this response. I can not find the place where data of select-fields are stored in app-code.
How can I store it correctly into database?
Using getStorageType 'json-array' results in wrong database scheme which bolt is not able to solve.
You can have a look on the code here:
https://github.com/osfriese/bolt-boxselect/tree/develope
Please help. Thanks
Tobi
I found the solution - more or less.
Sadly it is hardcoded in src/Content.php.
If you want a custom fieltype wich stores array values you have to change the select case in function getValues to:
default:
if (is_array($this->values[$field])) {
$newvalue[$field] = json_encode($this->values[$field]);
}else{
$newvalue[$field] = $this->values[$field];
}
break;
And in setValues there is a $serializedFieldTypes = array(...) where you have to manual add your custom field type.
Sadly this is not practical for extentions. But I will update my github with my changed Content.php for people who want to have a look.
When I was searching for an solution I reviewed a lot of source code of bolt master branch at github. For version 2.3 the storage layer is completely rebuild and as it seems there will be no need for any changes than. So hopefully with version >=2.3 the extention will work out of the box.
Nevertheless getStorageType() just just affect database field type and bolt just accepts 'text' here.
Hope I can help some people by answering my own question.
Thanks
Tobi
I have an xPages form editing a document, which can be edited automatically (as a datasource) coming frme a view. But you can also input directly (in an input field) the key of the document; then (if it exists) it will be searched in the database (converting the key in an UNID).
The matter is that in this case it is not the currentDocument and custom controls tests (for example for displaying buttons) do not work.
So my question is how to "convert" a programmatically searched document in the database (by UNID) to the normal datasource currentDocument, so normal controls can be apply to it too ?
Thanks if you know.
Store the Unid in the session and compute the data source from there - or open the Form with the matching URL parameter
Your problem is in the URL: it does not contains params to initialize default data source. This is IMHO the simplest way to fix it: native Domino links and XPages.
I am not sure whether it will help, it depends on actual value of context.getUrl(). If it doesn't, you need to redirect to URL you compute from UNID, as Stephan suggested.
Seems like a simple question, but I can't see where this is set.
I created a custom object, Account Thing, which is related to Accounts with a Master-Detail relationship.
It has a text area field, Body.
It has a Search Results Layout, and if i search for something contained in Body, a result returns.
I created another analogous custom object, Contact Thing. It also has a text area field, Body.
It does not have a Search Results Layout. If i search for something contained in Body, nothing returns. Looking at the list of objects being searched in the results page, Account Thing is listed, but not Contact Thing (or any other custom object i have created)
I'm thinking there must be a flag or search setting that i set for Account Thing, but I can't find it now.
I looked under App Setup > Customize > Search > Search Settings,
but there is no relevant config there.
Any help is appriciated!
I did some digging and found the solution to this issue.
Apparently only Custom Objects that have their own tab are included in search results.
I had somehow created a tab for Account Thing (but removed it from view), but not for
any of the other Custom Objects. After I added a tab, Contact Things were returned in relevant searches.
One other side piece of info is that the body was a Rich Text type, not a standard Text Area. So that explains why it is searchable.
Are you sure the Body on Account think uses a text area? I didn't think those would be searchable as you can't use them in the where clause of a SOQL query so would be surprised if the system did search them. Other than that, is the object marked as 'Deployed' or 'In Development'? If the latter, it probably wouldn't appear.
Because this is a non-code question you may well get closed down here, please follow (and vote on some questions) my Salesforce Stack Exchange proposal, I'm putting it forward so that these kind of questions (which are valid Salesforce development questions) have somewhere to live on Stack Exchange network!