I am trying to use multiple fields in the url link section of the widget and for some reason, one of my fields is not being recognized for its value, it just shows up exactly how I put it in the link.
I have other urls in the widget that use multiple fields with no problem, so I am thinking it is something with the field itself. When I build the same string in an AGOL map popup is works. Here is the rest service I am using:
I just added your layer and used your link text in my eSearch test app and it worked as expected. I got a link url of http: //slco.org/surveyor/cf/test/displayImage.cfm?subdir=57&page_id=3693826
That is what I would expect to see. I have no idea why it is not working for me, I have been trying for a couple of days now. Is there anything with the way it is configured that would affect this on my end?
Not that I am aware of but if you start a new question where you can add an attachment then you can zip your config_Enhanced Search.json for me to look at. Also I tested this in 2.0.1.3 are you using a different version?
In light of this recent flurry of activity, I don't believe anyone has asked the most pertinent question: is there a link to some kind of "Buy Robert a Beer Fund"?
Try deleting the eSearch folder from your stemapp widgets folder (and your apps widgets folder if you have an app that already has the eSearch widget added) and then extract the new 2.0.1.3 version to the stemapp widgets folder (and to your apps widgets folder).
Nicholas - have you registered your wab dev with your portal? Added your re-direct urls? I ask because whether Portal or Online, dev still has a proxy to your node js dev machine url
I'm using your latest enhanced search widget for a web app builder (version 2.0) app that I've created. Your latest updated widget works great. I just had a few questions that I hope you can answer below:
1.) I'm using 2 search expressions as you can see below. One is a fuzzy license plate search and the other is the date ranges. Is there a way that I can have the start date default to it always being today's date -365 days? Currently, both the start & end dates are today's date. The dataset this is referencing only goes back 1 year per our retention policy.
2.) Is there a way for me to expand the size of this widget window when it loads? The date windows are cut off so it doesn't show the full date on initial load. I realize this will show up differently depending on users screen resolution.
3.) Can I have the "Limit search to map extent" option checked on by default?
Thank you in advance for any guidance you can provide,
1. Currently no. You are the second person to ask in the last couple of week so I need to really look into this possibility.
2. The default size of the widget is theme dependent. It looks like you are using the Dart Theme, and the Dart theme and the launchpad theme ignores any height and width values set in the main config.
3. Sure there is a setting for this at the bottom of the main settings page "Enable limit results to maps extent by default".
#2 additional info
You can make some code change to make the dart theme use the position height and width properties from the main config.
Open the[instal dir]\server\apps\[app#]\themes\DartTheme\widgets\DartController\Widget.js file and update this function as follows:
None of your attachments made it into the post. Document Comments do not give the ability to attach anything. You can add pictures but if you want to add an attachment then you should start a new question. Click the link below:
There is a new release of eSearch and I am very excited about the new features, like CSV export for the eSearch without using AT Widget, multiple summary fields, date range search improvements, web map popup usage, etc.
Thank you Robert. Appreciate the quick & detailed response. I will try and implement these updates and may have some further questions if you don't mind.
I downloaded your latest esearch widget that you released today (5/23). I unzipped it and copied the contents, overwriting the previous esearch I was using here
After this, I shut down the web app builder 2.0 .bat file and then re-initiated it. I then opened web app builder and went to add in the enhanced search widget that I had just copied in and when I configure it, I don't see the enhancements you listed above with the latest changes. For instance, I don't see where I can set the start date to today -365 days.
Am I doing something wrong? I just unzipped the esearch.zip attachment that you have above...is this the latest one?
Ah gotcha, I will try that. If I had configured the esearch widget previously, will it automatically now show the enhancements that I can leverage or should I delete that one and then bring the new esearch widget in fresh and reconfigure it?
Nevermind! I just added the latest esearch widget to my particular app and the enhancements show up now without have to bring it in new and re-configure...it looks great...thanks!
Apologies for all the comments. I have this checked on for the esearch widget in my app and I even updated the config.json in the particular app to read this:
However, when I launch my app, the parameter is still unchecked by default...any ideas on how I can get this to stay checked on by default?
Robert, thank you again for continuing to develop and support top of the line widgets. I have one question about installing this new version. If I have the last version installed do I just write over the contents of that widgets folder or would that break the functionality of Web Apps that are using the older version of the eSearch Widget? If so I will likely unzip this widget to a folder with a new name and using in new Web Apps going forward.
You should unzip the new version and replace the eSearch widget folder in the stemapp widgets folder. This will allow you to use the new version in any new apps. If you want to replace the eSearch widget in an existing app then you ALSO have to copy the new eSearch widget into the apps widgets folder. Doing this will not break that add as the configuration file for widget that have been configured in your app are kept in the apps configs folder and not the widgets folder.
Hi Robert Scheitlin, GISP, A colleague of mine encountered something interesting this morning while using the 'buffer' in enhanced search widget this morning that I wanted to bring your attention to.
On using a small buffer radius like 0.2 mile from a point, we could select all the parcels in the proximity. But on using a buffer distance of 0.5 miles, the tool does not select all parcels within the radius. I haven't set any maximum buffer distance in the widget. Any thoughts on why this is happening?
I believe by default there is a 1000 record limit on returned records for performance which is what you might be hitting when going from 0.2 to 0.5 miles. You can increase this limit on the mapservice, but it could negatively impact your apps performance so you would want to test it out first.
Thanks for the reply Michael and Robert. It indeed was the record limit issue.
For someone struggling with similar issue, here are the steps to increase the limit:
Log into ArcGIS Server Manager and find the map service you are interested in.
When you find the service, click on the pencil icon next to the service name which lets you edit the service details.
When editing the service, click on the tab on the left which says "Parameters" and then there is a setting under properties called "Maximum number of records returned by server" - you should be able to change the value there. By default, the number is 1000.
Select "Save and Restart" when done editing to save the saves and restart the service.
Copying the latest version to the stemapp folder only update the eSearch for newly created apps. If you want to update an existing app that already has eSearch added then you have to overwrite the eSearch folder in the apps widget directory
I copied the eSearch to replaced the old folder in client\stemapp\widget. And then create a new app, but when I try to add the eSearch to this new app, the eSeach widget is not on the list.
make sure you replace the whole eSearch folder and that you did not accidentally add it inside an additional parent folder(i.e. stemapp/widgets/eSearch/eSearch).
I love the updates to the new widget! I have enabled the Export to CSV function and noticed that some fields are showing up in the csv that are not in my included fields. These fields also are empty in the table, there is just the header. I think it may have to do with the url search links since the fields are the same ones I use to build a url search string. Is there anything I can do in the code to only have the csv table include fields I have specified to include in my results?
After I restart the .bat, the new eSaerch is come. But I can not see the export CSV when I got the result. Do I need to do any configuration to show the Export CSV?
Thank you very much for the info below. This worked perfect for my app that uses the Dart Theme. Would this same logic apply if I had an app using the Launchpad Theme?
I do not see a "LaunchpadController" folder through my app# directory path in order to edit the Widget.js file...
Thank you in advance,
Mike
#2 additional info
You can make some code change to make the dart theme use the position height and width properties from the main config.
Open the[instal dir]\server\apps\[app#]\themes\DartTheme\widgets\DartController\Widget.js file and update this function as follows:
The ability to display the sum of more than 1 numeric fields will come in very handy.
Here I am displaying the Total Number of Students, and Teachers from the selected schools.
I can easily display the Total Population from selected cities:
I can press the More option to see more summary results:
This is a brilliant enhancement.
When you click on a record, the Pop-up window shows the complete list of attributes.
I like the Export All to CSV link right on the Results pane.
However, only the items in the Results pane were exported.
PLACE
Population
Sq. Miles
The values from the items in the Pop-up window did not make it through:
Category
Incorporated
MedianAge
AvgHHSize
CityData – This is the hyperlink field
Let’s see how the Export All to CSV link behaves in the Attribute Table.
Open Attribute Table from Layer = Search Results: Places
All the attributes are displayed:
Click on the Export All to CSV link from the Options pull down:
Now I see all the item values exported correctly.
I would like to submit an enhancement request to make the Export All to CSV link on the Results pane behave the same way as the Export All to CSV link on the Attribute Table.
Thanks for the quick fix on making the Identify Title to appear in black in the Launchpad Theme.
I disagree with your comment re an enhancement to the "EXPORT ALL CSV" to display all information whether visible in the results display or not. By configuring the results panel to display specific information and only allowing that information to be exported is great. This gives the administrator control over what's available to be exported. Robert, you have got this functionality spot on.
I agrees that the multiple sums needs some work. The way that it is currently working is NOT what I had intended. The text at the bottom of the widget should update and the summary window should only show the full sum, not two sets of sums. I will get this fixed for the next release. The CSV export is not working as intended either as any field whether popup only or the main eSearch results. You should not have a column listed in the exported CSV that has no data in that column.
Rod Woodford I don't think Tapas was suggesting that all the map services columns would be exported, but just the columns and data included in the search results and any used in the popups.
The ability to display the sum multiple fields combined with the capability of selecting multi-part graphics in eSearch 2.0.1.4 gave us the perfect solution we needed in one of our Emergency Management applications.
We needed a quick and efficient way of finding the number of people, cats, and dogs that need to be evacuated in an emergency.
A typical situation may call for everyone to be evacuated within 3 miles of ground zero, plus an additional number that may lie 8 miles along the wind vector.
This is where multi-part graphics comes in real handy to define the affected evacuation sectors.
First I am using the Circle Tool to select all sectors within 3 miles of ground zero.
Next, I am using the Polygon Tool to select the evacuation sectors 8 miles along the wind vector.
When I press the Search button, I get the contamination area highlighted in orange.
The Total Population that needs to be evacuated is shown in the bottom of the Results Pane.
When I click on the [More...] button, I get the full summary results.
This is the quickest way to display how may persons, people with special needs, cats, dogs, etc., that need to be evacuated in an emergency where every minute counts.
As you can see, the ability to display the sum of multiple items was critical for our emergency app.
Thanks a lot for this wonderful widget. I have just a little question about the use of a proxy, if I need it or not. So as I am not an expert and would have to dig quite deeply into this, I just thought to ask for your advice. Here is my set up:
- The app is based on a map and layers accessible to everyone. Nevertheless some of the layers may come from different AGOL subscriptions or even from a Portal, but also available without login.
- The app contains your eSearch widget and the eBasemapGallery. Only the Attribute search tab is activated
- There are no routing, geometry etc. services used (which may consume credits).
- The app will be deployed on an Apache Web Server. Do you know about some online guidelines specifically for this configuration? (I already went through the blogposts and the WABv2.pdf, but these are mainly about doing it correctly on IIS)
- I deployed it already on my localhost via XAMPP, and it works without a proxy. Can I assume, that it will work also on a productive Web Server without proxy?
I really liked this widget under ArcGIS for Flex and I'm very happy for the enhancement under WebAppBuilder. After installing and configuring my app totally collapsed. Launching the app in a browser (IE, Firefox) the app appears (also the webmap) but clicking on a widget all of them are empty.
Did I make a mistake under configuring the widget (in AppBuilder) or the error comes from other general error? Is there a way to turn back (I don't have safety saving).
';
}
}
}
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 {
lingoThreadLangSelected(lang, '910880');
} catch (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(/