Hi James - there is a way to batch prepare a pick or user list. In the expression portion of the eSeach config.json you can supply a pipe seperated list of code and value pairs:
Hi Robert, thanks for your fantastic widget! Our eSearch config file has multiple unique expressions set up and I modified the PagingQueryTask.js file to boost the initialization performance a bit. I wanted to inform you of this scenario in case I'm missing a configuration element that can solve our problem.
Our map service has 100,000 records. We've set up expressions for a few of the fields (e.g. sqltext: FIELD12 = '[value]', uniquevalsfromfield: FIELD12) and we love that we then get autocomplete support within the search form. The problem is that the unique list of values is almost always about 200-500 entries... too many that we'd rather not predefine the list, but given our large number of records we're seeing a pretty bad initialization hit for all the QueryTask.executeForCount() requests.
This might bite us in the butt months from now, but I modified your code to force the "query.returnDistinctValues = true" logic branch in execute() function within PagingQueryTask.js. Basically, if this.version >= 10.1 I force this.query.returnDistinctValues = true and this.queryTask.execute().
Is there an eSearch configuration or map service option that I'm not aware of that will help in this scenario (large # of records, search/filter expressions (autocomplete search fields) based on fields containing ultimately only a few records in comparison to total number of records)?
Hello again, Robert. Another performance issue we've run into that required some JS tweaking is also related to our high record count and likelihood of a high number of results. With 100k records and the possibility of returning 2k or more records we found that editing the List.js file to remove the record "striping" logic improved display performance quite a lot. By removing the domClass.remove(), array.map(), and domClass.add() logic from within the clearSelection() method we were able to display 2700 results in 9 seconds (down from 34 seconds). I understand that our number of record, the number of results we allow might be larger than most, and that forcing display styles through CSS isn't ideal for most widget users but I just wanted to throw this out there. We also removed some of the domStyle.set() call within the add() function to help boost display performance.
Again, thanks for all your development work - the widgets are awesome!
So the result from your code change is that if your query even produced more results than the max feature count of your map service then you would not get all the unique values from that service. Yes it will definitely bite you if you ever hit that situation.
I see that I am running the clearSelection() method each time a record is added to the list and that could be optimized better if it was only run once all records are added. I will make this change in the next release. Thanks
Thank You so much for such a powerful widget. I have been been experimenting with it and I am having some issues with the widget.
Issue #1 - Show popups from webmap setting: I have a parcel layer which uses custom formatting in the webmap popup. I have custom formatted it so that it passes parcel id or account number as values to different web services and it works well in the webmap as well as when through app created using web appbuilder developer edition. However, when I enable this in esearch, it is giving me incomplete results. For example look at the screenshot below which is the default popup configured in webmap.
Correct Popup (Configured in Webmap) :
Incorrect Popup (Returned by esearch when show popups from webmap is used):
Notice that in the screenshot below, the popup is not showing a value for OssSystem type(Should be sewer) even though it is showing on the eSearch results and default webmap popup(See above)
.
Also the esearch returned popup is cutting off some url parameters.
Issue # 2 - Blank Popup Window : When Disable Search results pop-up is checked either globally or on individual Search configuration, when you perform a search and click on result on the map, it will show a blank popup panel window.
Blank Popup Window when using Disable Search Results
Issue # 2 seems to go away when you check Add Result as Operational Layer setting on the configuration settings.
I am using Version 2.2 of the Web appbuilder and version 2.2.1 of esearch. I am using Foldable theme. My ArcGIS Server, Desktop and Portal versions are 10.4.1.Parcel layer and its custom popup is enabled by default on application start.
I have tested it on brand new webappbuilder install and esearch as well as with other versions and still gives me same results. I would greatly appreciate any assistance.
I've also ran into issues when using custom webmap popups with the Use Popup From: Web Map option in eSearch. Except with mine, the search just fails without any response in the app. This error is thrown in the console:
Uncaught TypeError: Cannot read property '_fieldLabels' of undefined
at Object.<anonymous>(Widget.js?wab_dv=2.1:1494)
at Object.forEach (init.js:70)
at Object._createSearchResultLayer (Widget.js?wab_dv=2.1:1480)
at Object.search (Widget.js?wab_dv=2.1:2107)
at Object.<anonymous>(Widget.js?wab_dv=2.1:1773)
at Object.<anonymous>(init.js:63)
at Object.c [as onDrawEnd](init.js:119)
at Object._onDrawEnd (DrawBox.js?wab_dv=2.1:471)
at Object.<anonymous>(init.js:63)
at Object.<anonymous>(init.js:644)
In my case, I could create popups in eSearch that were almost identical to what I had created in the web map, so I just went that route.
Hi Ryan, Thank You for your reply. I found out at least part of the issue for my problem. It seems like web map is forgiving as far as case sensitivity on variable names such as TaxID is same as taxid. On the other hand, looks like eSearch is not. so when I had a parameter name taxid which is actually named TaxID on the Service definition, it gives you unexpected results. Changing the name to the correct case as the service definition seemed to solve the problem.
So you can see the popups are almost identical, I just gave my web map popup a title of "Parcels:". So this is not a big deal for me. I just mentioned it in case it was somehow related to the problem Anish was having.
Nice update Robert. Just as an fyi to all: My testing shows that for the attachment link to display in the popup, the user must activate the popup from a result in the results panel, and an attachement must be present for that feature. Simply clicking the graphic in the map will not display the link. Not a big deal to me or our users. Hope to see you in March.
Hi Tapas, I'd love to be able to integrate our accela data into enhanced search as well. Are you just using the XAPO datasets within the E Search? Or are you pulling data via the API? thanks!
Yes, we are indeed using Accela to track our permits at Maricopa County. We have turned on the XAPO (External Address, Parcel, and Owner) Search features within Accela 8.0. We are not using the API.
This makes it very easy to maintain the Accela GIS Integration. We have a Parcel Map Service with around 1.5 million parcel polygons, and an Address Point Map Service. By enabling the XAPO feature within Accela, we do not have to maintain a parallel internal database within Accela. This saves us a lot of headaches of having to keep the internal Accela Database in sync with the Parcel Map Service.
With the XAPO feature turned on, when you go into the Accela interface and use any of the Address, Parcel, or Owner portlets within the APO Tab, and perform a search, the software pulls the data from the external Parcel and Address Point map services. When you open the GIS Tab, a map shows up zoomed to the selected parcel.
All of this works smoothly.
So how does this all relate to Robert's Enhanced Search Widget?
We found that it is much easier to create a standalone Web Application incorporating the Enhanced Search Widget that finds a parcel based on an Address, Parcel Number or Owner search, and zooms to the selected parcel displaying all the attributes that can be exported readily into Excel.
So now we have two ways to get to a parcel. The end users have the familiar option to launch Accela, open the APO Tab, and enter an Address, Parcel Number or Owner Name, and then open the GIS Tab to display the map showing the parcel.
Or, the end user can bypass Accela, and open the Web App using Robert's Enhanced Search Widget and get to the results right away. As an added advantage, this also works on a Smartphone.
We also created a Web App using the Customizable HTML Viewer from Geocortex. This lets us find a parcel in less than 2 seconds thanks to the Elastic Search Engine incorporated into the Geocortex software. Without Elastic Search, it takes anywhere from 5 to 20 seconds to find a parcel from the feature class with about 1.5 million records.
Thanks Tapas, we are currently configuring the XAPO schema in our SDE database. I guess the only thing I'm still not grasping is how the XAPO data is linked to the Accela tables and how the information is pulled into webappbuilder. Is the XAPO joined to the Accela records somehow in the parcel map service? I probably need to do more reading on the topic.
The XAPO data is linked to the internal Accela Tables via the Unique ID field.
For the Parcel Map Service, we are using the Parcel Number as the Unique ID field.
Typically you would launch the Accela GIS Administration Page, and define the Map Integration Environment. This is where you get to add the Map Services that you want to include in the GIS Map.
At the very bottom of this Edit Integration Environment Page, there is a link named "Modify Additional Settings" under Additional Settings.
When you click on this link, it lets you set up the Accela XAPO Integration.
You would need to set up 3 Accela Reference Objects:
Address
Parcel
Owner
For each reference object, you must specify a unique ID.
In our situation, the Address Reference Object points to the AddressPoint Map Service.
The Parcel and Owner Reference Objects points to the Parcel Map Service. The Unique ID field is the Parcel Number in both cases.
Once you have set up these Reference Objects, you must launch the Accela Web Server, and open the Classic Tab.
Next, open the Admin Tools Tab and select "Standard Choices" under Agency Profile.
You must add 3 Standard Choices and enable them to make the XAPO architecture work within Accela.
These Standard Choices are:
EXTERNAL_ADDRESS_SOURCE
EXTERNAL_PARCEL_SOURCE
EXTERNAL_OWNER_SOURCE
Each of these Standard Choices must be configured with a set of Parameters.
Finally, under the Admin Tools Tab, open the GIS Tab and add a GIS Service.
Make sure the GIS Service ID matches the one you entered while adding the Map Services in the GIS Administration Page.
All of these parameters must be set up for Accela to Join its internal tables to the external Parcel and AddressPoint Map Services.
Robert, I was wondering if you could add "have their centroid in" to the spatial relationship task. I use this a lot for selecting parcels within a zoning district etc. Is this already an option? just named something else?
Thanks David your suggestion on the Userlist worked very nicely! The only issue I have is that it forces me to select something from the Userlist.
For example if I know its 1234West Street I am good, but if I don't know the No# and just enter West Street I'll get no results, is there a way to get multi results and the specific Userlist ones.
I have an app that i deployed with your Enhanced Basemap widget. I recently received some new imagery for our area and i was wondering since the application is deployed how do you add base maps to deployed applications? One other thing, is there a way to move/rearrange the basemaps in the basemap gallery widget?
I am using version 2.3 of your widget with the same version of webappbuilder and in my application, I realized that Search by Spatial tab is missing. Is there a reason why it is doing that?
As this is the eSearch widget thread and it is already 72 pages long, I will have to ask you to start a new question when it is about something other than the eSearch widget.
Robert, first of all thanks for all the work you do on these widgets. I noticed an issue with certain queries breaking the map window when a "Zoom to" was performed. Results were returned correctly in the widget, but the map would go gray and not display any features. After a lot of searching I finally figured out this was due to a scale range applied on the map service layer. Every time I performed a query that would zoom the map to a scale outside of the set range, the map would break. This was because no x,y values were being passed into the Export Map operation. Below is an example of the request URL I was seeing:
Anyways, getting rid of the scale range was the easy fix. Might be good to add this into the help documentation to save someone a headache. Also I have no idea if it's possible to alter the widget to get around this scale range issue. Let me know what you think.
Correct, querying on scale dependent layers can cause problems with the "zoom to" action if the zoom is outside of the set scale range. For example if I have a layer set to only be visible "In beyond" 1:100,000 and I perform a query that returns a results extent that takes the map window to 1:200,000, the map will break. In this scenario clicking on a specific feature in the results tab will also not show anything in the map.
To be clear the scale dependency I am talking about is set at the map service level.
';
}
}
}
catch(e){
}
}
}
if (newSub.getAttribute("slang").toLowerCase() != code_l.toLowerCase()) {
if (trLabelsHtml != "") {
var labelSname = "";
if(labelEle[i].querySelector("ul li:nth-child(1)").getAttribute("aria-hidden")){
labelSname = labelEle[i].querySelector("ul li:nth-child(1)").outerHTML;
}
labelEle[i].innerHTML = "";
labelEle[i].innerHTML = labelSname + trLabelsHtml;
}
}
}
}
}
catch(e){
}
}
}
/* V 2.0:3 = Store not translated reply id */
if(lingoRSXML.snapshotLength == 0){
if($scope.falseReplyID == "") {
$scope.falseReplyID = value;
}
}
/* Get translated Body of Replies/Comments */
var lingoRBXML = doc.evaluate(lingoRBExp, doc, null, XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null);
for(var i=0;i 0) {
var attachDiv = rootElement.querySelector('div.lia-quilt-row-main').querySelector('div.custom-attachments');
if (attachDiv) {
attachDiv = attachDiv.outerHTML;
}
else if(rootElement.querySelector('div.lia-quilt-row-main').querySelectorAll('#attachments').length > 0){
if ("TkbArticlePage" == "BlogArticlePage") {
attachDiv = rootElement.querySelector('div.lia-quilt-row-main .lia-message-body-content').querySelector('#attachments');
if (attachDiv) {
attachDiv = attachDiv.outerHTML;
}
else{
attachDiv = "";
}
}else{
attachDiv = rootElement.querySelector('div.lia-quilt-row-main').querySelector('#attachments').outerHTML;
}
}
else {
attachDiv = "";
}
/* Feedback Div */
var feedbackDiv = "";
var feedbackDivs = rootElement.querySelector('div.lia-quilt-row-main').querySelectorAll('div.lia-panel-feedback-banner-safe');
if (feedbackDivs.length > 0) {
for (var k = 0; k < feedbackDivs.length; k++) {
feedbackDiv = feedbackDiv + feedbackDivs[k].outerHTML;
}
}
}
else {
var attachDiv = rootElement.querySelector('div.lia-message-body-content').querySelector('div.Attachments.preview-attachments');
if (attachDiv) {
attachDiv = attachDiv.outerHTML;
} else {
attachDiv = "";
}
/* Everyone tags links */
if (document.querySelectorAll("div.TagList").length > 0){
var everyoneTagslink = document.querySelector('div.lia-quilt-row-main').querySelector(".MessageTagsTaplet .TagList");
if ((everyoneTagslink != null)||(everyoneTagslink != undefined)){
everyoneTagslink = everyoneTagslink.outerHTML;
}
else{
everyoneTagslink = "";
}
}
/* Feedback Div */
var feedbackDiv = "";
var feedbackDivs = rootElement.querySelector('div.lia-message-body-content').querySelectorAll('div.lia-panel-feedback-banner-safe');
if (feedbackDivs.length > 0) {
for (var m = 0; m < feedbackDivs.length; m++) {
feedbackDiv = feedbackDiv + feedbackDivs[m].outerHTML;
}
}
}
}
} catch (e) {
}
if (body_L == "") {
/* V 2.0:7 Replacing translated video data with source video data */
var newBodyVideoData = newBody.querySelectorAll('div[class*="video-embed"]');
angular.forEach($scope.videoData[value], function (sourceVideoElement, index) {
if (index <= (newBodyVideoData.length - 1)) {
newBodyVideoData[index].outerHTML = sourceVideoElement.outerHTML
}
});
/* V 2.0:7 = Replacing translated image data with source data */
var newBodyImageData = newBody.querySelectorAll('[class*="lia-image"]');
angular.forEach($scope.imageData[value], function (sourceImgElement, index) {
if (index <= (newBodyImageData.length - 1)) {
newBodyImageData[index].outerHTML = sourceImgElement.outerHTML;
}
});
/* V 2.0:7 = Replacing translated pre tag data with source data */
var newBodyPreTagData = newBody.querySelectorAll('pre');
angular.forEach($scope.preTagData[value], function (sourcePreTagElement, index) {
if (index <= (newBodyPreTagData.length - 1)) {
newBodyPreTagData[index].outerHTML = sourcePreTagElement.outerHTML;
}
});
}
var copyBodySubject = false;
if (body_L == "") {
copyBodySubject = true;
body_L = newBody.innerHTML;
}
/* This code is written as part of video fix by iTalent */
/* try{
var iframeHTMLText = body_L;
var searchIframeText = "<IFRAME";
var foundiFrameTag;
if (iframeHTMLText.indexOf(searchIframeText) > -1) {
foundiFrameTag = decodeHTMLEntities(iframeHTMLText);
foundiFrameTag = foundiFrameTag.split('src="')[1];
body_L = foundiFrameTag;
}
}
catch(e){
} */
/* This code is placed to remove the extra meta tag adding in the UI*/
try{
body_L = body_L.replace('<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />','');
}
catch(e){
}
/** We should not replace the source content if user profile language and selected target language matches with source language **/
if(showTrContent) {
var compiled = false;
rootElement.querySelectorAll('div.lia-message-body-content')[0].innerHTML = null
if("TkbArticlePage"=="IdeaPage"){
// var customAttachDiv = '';
rootElement.querySelectorAll('div.lia-message-body-content')[0].innerHTML = body_L + feedbackDiv ;
$compile(rootElement.querySelectorAll('div.lia-message-body-content')[0])($scope);
compiled = true;
/* Attach atttach div */
// document.querySelector("div.translation-attachments-"+value).innerHTML = attachDiv;
rootElement.querySelectorAll('div.lia-message-body-content')[0].insertAdjacentHTML('afterend',attachDiv);
if(rootElement.querySelectorAll('div.lia-quilt-idea-message .lia-message-body .lia-attachments-message').length > 1){
rootElement.querySelectorAll('div.lia-quilt-idea-message .lia-message-body .lia-attachments-message')[1].remove();
}
} else {
if("TkbArticlePage"=="TkbArticlePage"){
rootElement.querySelectorAll('div.lia-message-body-content')[0].innerHTML = body_L + feedbackDiv ;
}else{
rootElement.querySelectorAll('div.lia-message-body-content')[0].innerHTML = body_L + feedbackDiv + attachDiv;
compiled = true;
}
}
/* Destroy and recreate OOyala player videos to restore the videos in target languages which is written by iTalent as part of iTrack LILICON-79 */ /* Destroy and recreate OOyala player videos */
try{
// $scope.videoData[value][0].querySelector("div").getAttribute("id");
for(var vidIndex=0; vidIndex<$scope.videoData[value].length; vidIndex++){
if( $scope.videoData[value][vidIndex].querySelector("div") != null){
var containerId = LITHIUM.OOYALA.players[$scope.videoData[value][vidIndex].querySelector("div").getAttribute("id")].containerId;
videoId = LITHIUM.OOYALA.players[$scope.videoData[value][vidIndex].querySelector("div").getAttribute("id")].videoId;
/** Get the Video object */
vid = OO.Player.create(containerId,videoId);
/** Destroy the video **/
vid.destroy();
/** recreate in the same position */
var vid = OO.Player.create(containerId,videoId);
}
}
}
catch(e){
}
try{
for(var vidIndex=0; vidIndex<($scope.videoData[value].length); vidIndex++){
if($scope.videoData[value][vidIndex].querySelector('video-js') != null){
var data_id = $scope.videoData[value][vidIndex].querySelector('video-js').getAttribute('data-video-id');
var data_account = $scope.videoData[value][vidIndex].querySelector('video-js').getAttribute('data-account');
var data_palyer = $scope.videoData[value][vidIndex].querySelector('video-js').getAttribute('data-player');
var div = document.createElement('div');
div.id = "brightcove";
div.class = "brightcove-player";
div.innerHTML =
'(view in my videos)'
var data = div.getElementsByClassName("video-js");
var script = document.createElement('script');
script.src = "https://players.brightcove.net/" + data_account + "/" + data_palyer + "_default/index.min.js";
for(var i=0;i< data.length;i++){
videodata.push(data[i]);
}
}
}
for(var i=0;i< videodata.length;i++){
document.getElementsByClassName('lia-vid-container')[i].innerHTML = videodata[i].outerHTML;
document.body.appendChild(script);
}
}
catch(e){
}
if(!compiled){
/* Re compile html */
$compile(rootElement.querySelectorAll('div.lia-message-body-content')[0])($scope);
}
}
if (code_l.toLowerCase() != newBody.getAttribute("slang").toLowerCase()) {
/* Adding Translation flag */
var tr_obj = $filter('filter')($scope.sourceLangList, function (obj_l) {
return obj_l.code.toLowerCase() === newBody.getAttribute("slang").toLowerCase()
});
if (tr_obj.length > 0) {
tr_text = "Esri may utilize third parties to translate your data and/or imagery to facilitate communication across different languages.".replace(/lilicon-trans-text/g, tr_obj[0].title);
try {
if ($scope.wootMessages[$rootScope.profLang] != undefined) {
tr_text = $scope.wootMessages[$rootScope.profLang].replace(/lilicon-trans-text/g, tr_obj[0].title);
}
} catch (e) {
}
} else {
//tr_text = "This message was translated for your convenience!";
tr_text = "Esri may utilize third parties to translate your data and/or imagery to facilitate communication across different languages.";
}
try {
if (!document.getElementById("tr-msz-" + value)) {
var tr_para = document.createElement("P");
tr_para.setAttribute("id", "tr-msz-" + value);
tr_para.setAttribute("class", "tr-msz");
tr_para.style.textAlign = 'justify';
var tr_fTag = document.createElement("IMG");
tr_fTag.setAttribute("class", "tFlag");
tr_fTag.setAttribute("src", "/html/assets/langTrFlag.PNG");
tr_fTag.style.marginRight = "5px";
tr_fTag.style.height = "14px";
tr_para.appendChild(tr_fTag);
var tr_textNode = document.createTextNode(tr_text);
tr_para.appendChild(tr_textNode);
/* Woot message only for multi source */
if(rootElement.querySelector(".lia-quilt-forum-message")){
rootElement.querySelector(".lia-quilt-forum-message").appendChild(tr_para);
} else if(rootElement.querySelector(".lia-message-view-blog-topic-message")) {
rootElement.querySelector(".lia-message-view-blog-topic-message").appendChild(tr_para);
} else if(rootElement.querySelector(".lia-quilt-blog-reply-message")){
rootElement.querySelector(".lia-quilt-blog-reply-message").appendChild(tr_para);
} else if(rootElement.querySelector(".lia-quilt-tkb-message")){
rootElement.querySelector(".lia-quilt-tkb-message").appendChild(tr_para);
} else if(rootElement.querySelector(".lia-quilt-tkb-reply-message")){
rootElement.querySelector(".lia-quilt-tkb-reply-message").insertBefore(tr_para,rootElement.querySelector(".lia-quilt-row.lia-quilt-row-footer"));
} else if(rootElement.querySelector(".lia-quilt-idea-message")){
rootElement.querySelector(".lia-quilt-idea-message").appendChild(tr_para);
} else if(rootElement.querySelector('.lia-quilt-occasion-message')){
rootElement.querySelector('.lia-quilt-occasion-message').appendChild(tr_para);
}
else {
if (rootElement.querySelectorAll('div.lia-quilt-row-footer').length > 0) {
rootElement.querySelectorAll('div.lia-quilt-row-footer')[0].appendChild(tr_para);
} else {
rootElement.querySelectorAll('div.lia-quilt-column-message-footer')[0].appendChild(tr_para);
}
}
}
} catch (e) {
}
}
} else {
/* Do not display button for same language */
// syncList.remove(value);
var index = $scope.syncList.indexOf(value);
if (index > -1) {
$scope.syncList.splice(index, 1);
}
}
}
}
});
});
/* V 1.1:2 = Reply Sync button for multi source translation */
} catch(e){
console.log(e);
}
};
if((rContent != undefined) && (rContent != "")) {
drawCanvas(decodeURIComponent(rContent));
/** Update variable with selected language code **/
$scope.previousSelCode = code_l;
}
};
/**
* @function manageTranslation
* @description Managess the translation of given language for the thread
* @param {string} langCode - Language Code
* @param {string} tid - Thread ID
*/
$scope.manageTranslation = function (langCode, tid) {
//debugger;
$scope.showTrText = false;
/* V 2.0:5 = actualStatus variable introduced to indicate detailed connector status on UI. This variable holds the actual translation percentage */
$scope.transPercent = "";
$scope.actualStatus = "";
if (tid != "") {
var bulkTranslation = lithiumPlugin.bulkTranslation(langCode, tid);
bulkTranslation.then(function (trContent) {
if(trContent.body != "") {
$scope.showPreview(trContent.body, $scope.mszList, langCode);
if(langCode != "en-US") {
$scope.showTrText = true;
}
}
if((trContent.status != "NA") && trContent.status != null) {
// $scope.transPercent = String(trContent.status);
$scope.actualStatus = String(trContent.status);
} else {
// $rootScope.errorMsg = "Translation is in progress. Please check again a few minutes."
$rootScope.errorMsg = "Translation is in progress. Please retry in a few minutes."
}
$scope.workbench = trContent.wb;
/* V 2.0:4 = Trigger uncalled or delayed callbacks (documnet uploaded/translation completed from lithium).*/
if(trContent.callback == 'true') {
var trCompletCallback = lithiumPlugin.trCompletCallback(langCode, trContent.docID);
trCompletCallback.then(function (callback){
// $rootScope.errorMsg = "Downloading Translated content in " + langCode + " now. Please check again in a few minutes."
$rootScope.errorMsg = "Uploading content to translate. Please check again in a few minutes."
});
} else if (trContent.callback == 'upload') {
var trCompletUpload = lithiumPlugin.trCompletUpload(langCode, trContent.docID);
trCompletUpload.then(function (callback) {
//$rootScope.errorMsg = "Uploading content to translate. Please check again in a few minutes."
$rootScope.errorMsg = "Uploading content to translate. Please check again in a few minutes."
});
} else if ("many" == "one") {
$scope.updateOOS();
} else if("SmartConx" == "SmartConx"){
if ("many" == "many"){
$scope.updateOOS();
}
}else if ((trContent.status != null) && trContent.status.includes("100")) {
/* If everything fine then only check Out of Sync status */
$scope.updateOOS();
} else {
/* If translation perccent is less than 100 then show the percentage on UI */
$scope.transPercent = $scope.actualStatus;
}
});
}
}
/**
* @function selectThisLang
* @description Called on select dropdown.
* @param {string} lang - Language code
*
*/
$scope.selectThisLang = function (lang, anonymousFlag) {
/* 1.4:3 Update Analytics on language selection */
try {
setTimeout(()=>{
lingoThreadLangSelected(lang, '910880');
console.log("Language",lang);
},5000)
} catch (e) {
console.log(e);
}
/** Display Translated content **/
var getTranslation = lithiumPlugin.getTranslation(lang, "910880");
getTranslation.then(function (trContent) {
if (trContent.body != "") {
$scope.showPreview(trContent.body, $scope.mszList, lang);
} else {
//$rootScope.errorMsg = "Translation is in progress. Please check again in a few minutes."
$rootScope.errorMsg = "Translation is in progress. Please retry in a few minutes."
}
});
};
var decodeEntities = (function() {
// this prevents any overhead from creating the object each time
var element = document.createElement('div');
function decodeHTMLEntities (str) {
if(str && typeof str === 'string') {
// strip script/html tags
str = str.replace(/