I’m making changes to the transcription value of a field in my submission object based on some business logic in a custom Hyperscience flow. However, I don’t see this newly updated value on the UI during the flexible extraction afterwards - can someone help me understand why this is happening? Here’s how I’m making the change and forcing flexible extraction on this field:
for document in submission.get('documents', []):
for field in document.get('document_fields', []):
if field['output_name'] == 'some name' and field['transcription_normalized'] == 'old value':
field['transcription_normalized'] = 'new value'
field['process_flexible_extraction_type'] = 'FORCE'
I don’t see the ‘new value’ on the UI, still only the ‘old value’.
Related
I added a sublist field on a transaction. For instance a Sales Order. When you add the field via user event script, it positions the field at the end of the sublist. Is there a way to position the field? This can't be accomplished in the UI as the field is added via script. It's a select type field, so I am trying to modify the list values with client script and can only do that if the field is created in my user even script. My code works perfectly fine, it's just the field is at the end of the sublist line(far right and have to scroll). I am using SuiteScript 1.0 but am open to using 2.0 if I need to.
This is for suitescript 2.0
This has sort of turned into two questions so I will give an answer for one and then the solution, for clarity. The short answer is you cannot move a sublist field when created in a user event (however there is a solution to that.)
you can add a sublist field by getting the sublist and using the sublist.addField method.
function beforeLoad(context){
var form = context.form;
var sublist = form.getSublist({
id : 'item'
});
sublist.addField({
id: 'fieldid you want to use for script reference ect.',
type: serverWidget.FieldType.CHECKBOX, //any supported TYPE
label: 'Label users will see in sublist'
});
}
If done this way, there will be a new column on the end of the items sublist that cannot be moved.
To be able to move the location of the column do the following.
Navigate to
Customization
Lists, Records, & Fields
Transaction Line Fields
add a new field and apply to the sublist you want it used on.
you can assign and id which will be prefixed with custcol so start your id with an _ and give it a name.
Once this is complete you can access the field by id and change the value in your user event script before load
function beforeLoad(context){
var form = context.form;
var sublist = form.getSublist({
id : 'item'
});
sublist.setSublistValue({
id: 'customcol_id_created_in_ui',
line: 1, //line you want to access if needing to set all you will have to loop through and set each one.
value: "your value"
});
}
If you go to the API reference and look at the ui/serverWidget module and navigate to sublist you can find all of the methods and options for manipulating sublist there.
In SuiteScript 2.x you would use the N/ui/serverWidget module, create the field and then use the Form.insertField(options) method, passing in the field you created as options.field and the existing field which you want to insert your field before as options.nextfield. Note that Form refers to the form object passed to the user event script in the scriptContext.
i don't believe there is a SS1.0 equivalent.
[PdfTron 5.2]
I have a PDF form with text and date fields. I want to find the date fields.
I can get the actions of the field with getActions().
field.getActions()
returns
{"F":[{"yc":"JavaScript","Gt":"AFDate_FormatEx(\"dd.mm.yyyy\");"}],
"K":[{"yc":"JavaScript","Gt":"...);","ey":null}]}
As you can see, the date is in actions.F[0].Gt. But checking actions.F[0].Gt
for "AFDate" seems wrong, that's too low-level.
Is there a better API function to find out, that I have a date field?
Thank you.
You are correct. The Gt property is obfuscated and minified which is volatile and not meant to be used. If you require an API, you should refer to our documentation. Everything should be available there except a few (one of which will be used below), but feel free to contact us if you do need help!
Unfortunately, there is no API currently to get that type. From my limited understanding, the "type" of a field is determined by the attached actions and not simply a specific type or flag. This suggests all fields are just text fields with special formatting actions to make it look and feel like its a date or numeric field.
In this case, you will have to check the formatting action (F) as you have already noticed for the date formatting function (AFDate_FormatEx). To get the JavaScript from that action, you should use the javascript property on the action which was not in the documentation. However, you can see it if you console log the action.
Here is an example:
const dateActionJs = /.+:"AFDate_FormatEx\(.*/;
instance.docViewer.on('annotationsLoaded', () => {
const annotations = annotManager.getAnnotationsList();
annotations.forEach(annot => {
const actions = annot.getField().getActions();
if (actions.F && actions.F[0] && actions.F[0].javascript && dateActionJs.test(actions.F[0].javascript)) { // F = Format Action
console.log('Found Date');
}
});
});
Let me know if this helps!
EDIT: You can search for AFDate instead of AFDate_FormatEx which will be sufficient.
For a custom page type, I have a multiple choice form filed as seen in image 1 and 2. I was able to set it up (using jquery) so that when I click on other checkboxes belonging to a another field, the checkbox Label and value of this field is changed accordingly as seen in image 3 - 'Author1', 'Author2', 'Author3' were replaced with something else.
The problem is when I hit the Save button, all of my new label/value are not Saved, but the checkbox value and label return to its original value.
Is there a way to make it so that these checkboxes can accept new value and the new value can be saved. Thanks!
Where does authors values come from? Database? You should be able to use SQL query as data source for multiple choice control. This will allow you to store actual values into database whenever you save a page on the Form tab.
So the idea is to load actual values, replace them with 'AuthorN' and change back to original value when checked.
I've set up an example which might help you. I've created a form with three fields:
FirstAuthor
Type: Integer
Form control: Radio buttons
Data source: SQL Query (select userid,username from cms_user)
Has depending fields: true
SecondAuthor
Type: Integer
Form control: Radio buttons
Data source: SQL Query (select userid,username from cms_user)
Has depending fields: true
OrderedAuthors
Type: Text (1000)
Form control: Label
Default value: {% (if(firstauthor>0) { GlobalObjects.Users.Where("userid="+firstauthor)[0].UserName } else {""}) + ", " + (if(secondauthor>0) {GlobalObjects.Users.Where("userid="+secondauthor)[0].UserName} else {""} #%}
Depends on another field: true
I guess you have a list of authors somewhere in the database so you can just replace CMS_User table with your table. Then all you need to do is to adjust the macro in the third field to give you results you want.
I'm using the search portlet in certain areas of my website, but I'd like to restrict the results to only search for a specific content type: for example only search the news items, or only show Faculty Staff Directory profiles.
I know you can do this after you get to the ##search form through that "filter" list, but is there a way to start with the filter on, so that the "Live Search" results only show the relevant results (i.e. only news items or only profiles).
I suspect you know it already, but just to be sure: You can globally define which types should be allowed to show up in searchresults in the navigations-settings of the controlpanel, and then export and include the relevant parts to your product's GS-profile-propertiestool.xml.
However, if you would like to have some types excluded only in certain sections, you can customize Products.CMFPlone/skins/plone_scripts/livesearch_reply, which already filters the types, to only show "friendly_types" around line 38 (version 4.3.1) and add a condition like this:
Edit:
I removed the solution to check for the absolute_url of the context, because the context is actually the livesearch_reply in this case, not the current section-location. Instead the statement checks now, if the referer is our section:
REQUEST = context.REQUEST
current_location = REQUEST['HTTP_REFERER']
location_to_filter = '/fullpath/relative/to/siteroot/sectionId'
url_to_filter = str(portal_url) + location_to_filter
types_to_filter = ['Event', 'News Item']
if current_location.find(url_to_filter) != -1 or current_location.endswith(url_to_filter):
friendly_types = types_to_filter
else:
friendly_types = ploneUtils.getUserFriendlyTypes()
Yet, this leaves the case open, if the user hits the Return- or Enter-key or the 'Advanced search...'-link, landing on a different result-page than the liveresults have.
Update:
An opportunity to apply the filtering to the ##search-template can be to register a Javascript with the following content:
(function($) {
$(document).ready(function() {
// Let's see, if we are coming from our special section:
if (document.referrer.indexOf('/fullpath/relative/to/siteroot/sectionId') != -1) {
// Yes, we have the button to toggle portal_type-filter:
if ($('#pt_toggle').length>0) {
// If it's checked we uncheck it:
if ($('#pt_toggle').is(':checked')) {
$('#pt_toggle').click();
}
// If for any reason it's not checked, we check and uncheck it,
// which results in NO types to filter, for now:
else {
$('#pt_toggle').click();
$('#pt_toggle').click();
}
// Then we check types we want to filter:
$("input[value='Event']").click();
$("input[value='News Item']").click();
}
}
})
})(jQuery);
Also, the different user-actions result in different, inconsistent behaviours:
Livesearch accepts terms which are not sharp, whereas the ##search-view only accepts sharp terms or requires the user to know, that you can append an asterix for unsharp results.
When hitting the Enter/Return-key in the livesearch-input, the searchterm will be transmitted to the landing-page's (##search) input-element, whilst when clicking on 'Advanced search...' the searchterm gets lost.
Update:
To overcome the sharp results, you can add this to the JS right after the if-statement:
// Get search-term and add an asterix for blurry results:
var searchterm = decodeURI(window.location.search.replace(new RegExp("^(?:.*[&\\?]" + encodeURI('SearchableText').replace(/[\.\+\*]/g, "\\$&") + "(?:\\=([^&]*))?)?.*$", "i"), "$1")) + '*';
// Insert new searchterm in input-text-field:
$('input[name=SearchableText]').val(searchterm);
Update2:
In this related quest, Eric Brehault provides a better solution for passing the asterix during submit: Customize Plone search
Of course you can also customize the target of advanced-search-link in livesearch_reply, respectively in the JS for ##search, yet this link is rather superfluous UI-wise, imho.
Also, if you're still with Archetypes and have more use-cases for pre-filtered searchresults depending on the context, I can recommend to have a look at collective.formcriteria, which allows to define search-criteria via the UI. I love it for it's generic and straightforward plone-ish approach: catalogued indizi and collections. In contradiction to eea.facetednavigation it doesn't break accessibility and can be enhanced progressively with some live-search-js-magic with a little bit of effort, too. Kudos to Ross Patterson here! Simply turn a collection (old-style) into a searchform by changing it's view and it can be displayed as a collection-portlet, as well. And you can decide which criteria the user should be able to change or not (f.e. you hide the type-filter and offer a textsearch-input).
Watch how the query string changes when you use the filter mechanism on the ##search page. You're simply adding/subtracting catalog query criteria.
You may any of those queries in hidden fields in a search form. For example:
<form ...>
....
<input type="hidden" name="portal_type" value="Document" />
</form>
The form on the query string when you use filter is complicated a bit by its record mechanism, which allows for some min/max queries. Simple filters are much easier.
How do you set a richText value with replaceItemValue from a rich tect control?
I found this bit of code here:
http://www.bleedyellow.com/blogs/martin/entry/save_a_richtext_field_from_a_xpage_to_a_document?lang=en_us
var doc = configuratieformulieren.getDocumentByKey("ConfiguratieIVNL", true);
if(doc == null){
return;
}else{
var titel = getComponent("inputTextIBPTitelIVNL").getValue();
doc.replaceItemValue("IBPTitel",titel);
var inhoud = getComponent("inputRichTextIBPInhoudIVNL").getValue();
if (inhoud != null){
var contentType = doc.getMIMEEntity("IBPInhoud").getContentType();
var encoding = doc.getMIMEEntity("IBPInhoud").getEncoding();
var str = session.createStream();
inhoud.toString();
str.writeText(inhoud.toString());
doc.getMIMEEntity("IBPInhoud").setContentFromText(str, contentType, encoding);
}
doc.save(true, true);
}
sessionScope.put("FormulierIVNLInfoBeschPG","Lezen");
Is it correct? It looks like this code depends on the fact that the field already exists. How id this handled if the field does not exist? Is there and easier way to set a field value to the contents of a rich text control?
Let data sources do the heavy lifting. For a long and boring (but thorough) explanation of why, read this article. But here's the quick version:
Don't use:
getComponent("someID").getValue()
Instead, use:
someDataSource.getValue("someFieldName")
This is always a more efficient way to access data: instead of having to spider through the component tree to locate a match, it goes straight to the data source, which the component would have to ask anyway if you asked it what its value is.
Similarly, don't use:
someDataSource.replaceItemValue("someFieldName", someValue)
Instead, use:
someDataSource.setValue("someFieldName", someValue)
The latter is much more flexible on input type. The data source already contains all the logic for determining what to do based on whether the value is text, date, number, rich text, file upload, etc. No need to duplicate any of that logic in your own code.
So if the goal is to update a separate document based on data in the current document, just define a separate document data source that points to the document you want to update. Then it's literally this simple:
configData.setValue("RichTextData", currentDocument.getValue("RichTextData"));
configData.save();
With the above code, if the field you specify on the current document is rich text, then the item it creates on the other document will be rich text. If it's any other type on the current document, it will be the same type on the other document. With getValue() and setValue(), you don't have to pay attention to the data type... the data source handles all of that for you.
For bonus points, scope configData to applicationScope so that any updates to it are immediately cached for all users... or sessionScope if the document you're updating is user-specific.
I was able to solve my orginal issue. To expand on my issue I was having problems with using a dialog box to create Form / Document B from Form / Document A using a dialog box on Form A. What was happening was any changes to Form B would be saved to Document A's datasource.
I found the ingoreRequestParams on Form B's datasource, set it and that solved my problem with Form B writing to Form A document.