Content Management and Capture

We're running ICN 3.0.11 and Daeja Viewer Virtual 5.0.11 and using a custom plugin that just loads a ContentViewer feature in an iframe, and takes (CM8) document metadata as input to open the doc for users.  I've been comparing the Merge & Split functionality in our plugin version against a default Search/Browse desktop feature, and am noticing some different behavior.  In our plugin we open tabs/docs with this command below, which is taken from this IBM documentation: How to integrate Content Navigator with your applications to view content (ibm.com).

_openDocument: function(repositoryId, docId, classId, vsId, version) {
     var repository = ecm.model.desktop.getRepository(repositoryId);
     repository.retrieveItem(docId, lang.hitch(this, function(item) {
          this.contentViewer.open(item, false);
     }), classId, version, vsId);
}

For the most part it works ok, but I've noticed some different cosmetic functionality compared to the default desktop feature.  If I use the Search feature, find my document, right-click and pick Merge and Split, then modify the document (reorder the pages) the toolbar will change so that the Check-In button is lit up, and the tab will change to show a Locked icon indicating the doc is now checked-out and locked for editing.

If I open a document using the above javascript command and follow the same steps the Check-In button does not light up until I click somewhere else on the screen after making my change, and the Locked icon never shows up.

I've determined it's not a bug in our plugin itself.  I can open the Merge & Split window from the default Search feature, use that command above in the javascript console to open a new doc, and it will also have these issues.  That means there is something inherently different in the process above vs how the Search feature opens the Merge & Split window.  As if maybe it opens the tab and also goes through a post-create process of assigning change events to things so the UI will update based on what you do.

I've had other cosmetic issues with the Merge & Split window, and I'm wondering if those also tie back to this inherent difference in how the tabs are opened.

Can anyone tell me what the Search feature is doing differently?  Is it something I can add to my _openDocument method so it behaves appropriately?  These aren't showstopper problems, but they are inconveniences to the many users of our product.

Thanks!

------------------------------
Brad Pratt
------------------------------
​
#IBMContentNavigator(ICN)​#DaejaViewONE​​

hello Brad,

Sorry for the delay in reverting. SMEs for this topic were unavailable last week. We will provide a response soon.

------------------------------
Nanda Pilaka
IBM Content Navigator Support
------------------------------

Original Message:
Sent: Fri February 03, 2023 03:56 PM
From: Brad Pratt
Subject: Daeja Merge & Split issues

We're running ICN 3.0.11 and Daeja Viewer Virtual 5.0.11 and using a custom plugin that just loads a ContentViewer feature in an iframe, and takes (CM8) document metadata as input to open the doc for users.  I've been comparing the Merge & Split functionality in our plugin version against a default Search/Browse desktop feature, and am noticing some different behavior.  In our plugin we open tabs/docs with this command below, which is taken from this IBM documentation: How to integrate Content Navigator with your applications to view content (ibm.com).

_openDocument: function(repositoryId, docId, classId, vsId, version) {
     var repository = ecm.model.desktop.getRepository(repositoryId);
     repository.retrieveItem(docId, lang.hitch(this, function(item) {
          this.contentViewer.open(item, false);
     }), classId, version, vsId);
}

For the most part it works ok, but I've noticed some different cosmetic functionality compared to the default desktop feature.  If I use the Search feature, find my document, right-click and pick Merge and Split, then modify the document (reorder the pages) the toolbar will change so that the Check-In button is lit up, and the tab will change to show a Locked icon indicating the doc is now checked-out and locked for editing.

If I open a document using the above javascript command and follow the same steps the Check-In button does not light up until I click somewhere else on the screen after making my change, and the Locked icon never shows up.

I've determined it's not a bug in our plugin itself.  I can open the Merge & Split window from the default Search feature, use that command above in the javascript console to open a new doc, and it will also have these issues.  That means there is something inherently different in the process above vs how the Search feature opens the Merge & Split window.  As if maybe it opens the tab and also goes through a post-create process of assigning change events to things so the UI will update based on what you do.

I've had other cosmetic issues with the Merge & Split window, and I'm wondering if those also tie back to this inherent difference in how the tabs are opened.

Can anyone tell me what the Search feature is doing differently?  Is it something I can add to my _openDocument method so it behaves appropriately?  These aren't showstopper problems, but they are inconveniences to the many users of our product.

Thanks!

------------------------------
Brad Pratt
------------------------------
​
#IBMContentNavigator(ICN)​#DaejaViewONE​​

ICN should check out the document automatically when ContentViewer.open() or ContentViewer.openInMergeSplit() is called and the cmViewerAutoCheckout config parameter is enabled.

https://www.ibm.com/docs/en/content-navigator/3.0.13?topic=navigator-configuration-parameters

------------------------------
ANDY Choi
------------------------------

Original Message:
Sent: Fri February 03, 2023 03:56 PM
From: Brad Pratt
Subject: Daeja Merge & Split issues

We're running ICN 3.0.11 and Daeja Viewer Virtual 5.0.11 and using a custom plugin that just loads a ContentViewer feature in an iframe, and takes (CM8) document metadata as input to open the doc for users.  I've been comparing the Merge & Split functionality in our plugin version against a default Search/Browse desktop feature, and am noticing some different behavior.  In our plugin we open tabs/docs with this command below, which is taken from this IBM documentation: How to integrate Content Navigator with your applications to view content (ibm.com).

_openDocument: function(repositoryId, docId, classId, vsId, version) {
     var repository = ecm.model.desktop.getRepository(repositoryId);
     repository.retrieveItem(docId, lang.hitch(this, function(item) {
          this.contentViewer.open(item, false);
     }), classId, version, vsId);
}

For the most part it works ok, but I've noticed some different cosmetic functionality compared to the default desktop feature.  If I use the Search feature, find my document, right-click and pick Merge and Split, then modify the document (reorder the pages) the toolbar will change so that the Check-In button is lit up, and the tab will change to show a Locked icon indicating the doc is now checked-out and locked for editing.

If I open a document using the above javascript command and follow the same steps the Check-In button does not light up until I click somewhere else on the screen after making my change, and the Locked icon never shows up.

I've determined it's not a bug in our plugin itself.  I can open the Merge & Split window from the default Search feature, use that command above in the javascript console to open a new doc, and it will also have these issues.  That means there is something inherently different in the process above vs how the Search feature opens the Merge & Split window.  As if maybe it opens the tab and also goes through a post-create process of assigning change events to things so the UI will update based on what you do.

I've had other cosmetic issues with the Merge & Split window, and I'm wondering if those also tie back to this inherent difference in how the tabs are opened.

Can anyone tell me what the Search feature is doing differently?  Is it something I can add to my _openDocument method so it behaves appropriately?  These aren't showstopper problems, but they are inconveniences to the many users of our product.

Thanks!

------------------------------
Brad Pratt
------------------------------
​
#IBMContentNavigator(ICN)​#DaejaViewONE​​

The document is being checked out, but the UI does not update appropriately.  If the document is opened with the contentviewer.open() command the lock icon never shows on the tab, and the check in/out and cancel checkout buttons don't update automatically as soon as a change is made, you have to click a second time on the screen for it to update.

The only problem is the UI not updating.

------------------------------
Brad Pratt
------------------------------

Original Message:
Sent: Mon February 13, 2023 01:32 PM
From: ANDY Choi
Subject: Daeja Merge & Split issues

ICN should check out the document automatically when ContentViewer.open() or ContentViewer.openInMergeSplit() is called and the cmViewerAutoCheckout config parameter is enabled.

https://www.ibm.com/docs/en/content-navigator/3.0.13?topic=navigator-configuration-parameters

------------------------------
ANDY Choi

Original Message:
Sent: Fri February 03, 2023 03:56 PM
From: Brad Pratt
Subject: Daeja Merge & Split issues

We're running ICN 3.0.11 and Daeja Viewer Virtual 5.0.11 and using a custom plugin that just loads a ContentViewer feature in an iframe, and takes (CM8) document metadata as input to open the doc for users.  I've been comparing the Merge & Split functionality in our plugin version against a default Search/Browse desktop feature, and am noticing some different behavior.  In our plugin we open tabs/docs with this command below, which is taken from this IBM documentation: How to integrate Content Navigator with your applications to view content (ibm.com).

_openDocument: function(repositoryId, docId, classId, vsId, version) {
     var repository = ecm.model.desktop.getRepository(repositoryId);
     repository.retrieveItem(docId, lang.hitch(this, function(item) {
          this.contentViewer.open(item, false);
     }), classId, version, vsId);
}

For the most part it works ok, but I've noticed some different cosmetic functionality compared to the default desktop feature.  If I use the Search feature, find my document, right-click and pick Merge and Split, then modify the document (reorder the pages) the toolbar will change so that the Check-In button is lit up, and the tab will change to show a Locked icon indicating the doc is now checked-out and locked for editing.

If I open a document using the above javascript command and follow the same steps the Check-In button does not light up until I click somewhere else on the screen after making my change, and the Locked icon never shows up.

I've determined it's not a bug in our plugin itself.  I can open the Merge & Split window from the default Search feature, use that command above in the javascript console to open a new doc, and it will also have these issues.  That means there is something inherently different in the process above vs how the Search feature opens the Merge & Split window.  As if maybe it opens the tab and also goes through a post-create process of assigning change events to things so the UI will update based on what you do.

I've had other cosmetic issues with the Merge & Split window, and I'm wondering if those also tie back to this inherent difference in how the tabs are opened.

Can anyone tell me what the Search feature is doing differently?  Is it something I can add to my _openDocument method so it behaves appropriately?  These aren't showstopper problems, but they are inconveniences to the many users of our product.

Thanks!

------------------------------
Brad Pratt
------------------------------
​
#IBMContentNavigator(ICN)​#DaejaViewONE​​

You should be able to see how the checkout state on the tab is being updated by putting breakpoints at the following locations.

ecm.widget.viewer.DocViewer.onItemUpdate()
ContentViewer.ContentViewerTab.updateButtonState()

------------------------------
ANDY Choi
------------------------------

Original Message:
Sent: Mon February 13, 2023 01:40 PM
From: Brad Pratt
Subject: Daeja Merge & Split issues

The document is being checked out, but the UI does not update appropriately.  If the document is opened with the contentviewer.open() command the lock icon never shows on the tab, and the check in/out and cancel checkout buttons don't update automatically as soon as a change is made, you have to click a second time on the screen for it to update.

The only problem is the UI not updating.

------------------------------
Brad Pratt

Original Message:
Sent: Mon February 13, 2023 01:32 PM
From: ANDY Choi
Subject: Daeja Merge & Split issues

ICN should check out the document automatically when ContentViewer.open() or ContentViewer.openInMergeSplit() is called and the cmViewerAutoCheckout config parameter is enabled.

https://www.ibm.com/docs/en/content-navigator/3.0.13?topic=navigator-configuration-parameters

------------------------------
ANDY Choi

Original Message:
Sent: Fri February 03, 2023 03:56 PM
From: Brad Pratt
Subject: Daeja Merge & Split issues

We're running ICN 3.0.11 and Daeja Viewer Virtual 5.0.11 and using a custom plugin that just loads a ContentViewer feature in an iframe, and takes (CM8) document metadata as input to open the doc for users.  I've been comparing the Merge & Split functionality in our plugin version against a default Search/Browse desktop feature, and am noticing some different behavior.  In our plugin we open tabs/docs with this command below, which is taken from this IBM documentation: How to integrate Content Navigator with your applications to view content (ibm.com).

_openDocument: function(repositoryId, docId, classId, vsId, version) {
     var repository = ecm.model.desktop.getRepository(repositoryId);
     repository.retrieveItem(docId, lang.hitch(this, function(item) {
          this.contentViewer.open(item, false);
     }), classId, version, vsId);
}

For the most part it works ok, but I've noticed some different cosmetic functionality compared to the default desktop feature.  If I use the Search feature, find my document, right-click and pick Merge and Split, then modify the document (reorder the pages) the toolbar will change so that the Check-In button is lit up, and the tab will change to show a Locked icon indicating the doc is now checked-out and locked for editing.

If I open a document using the above javascript command and follow the same steps the Check-In button does not light up until I click somewhere else on the screen after making my change, and the Locked icon never shows up.

I've determined it's not a bug in our plugin itself.  I can open the Merge & Split window from the default Search feature, use that command above in the javascript console to open a new doc, and it will also have these issues.  That means there is something inherently different in the process above vs how the Search feature opens the Merge & Split window.  As if maybe it opens the tab and also goes through a post-create process of assigning change events to things so the UI will update based on what you do.

I've had other cosmetic issues with the Merge & Split window, and I'm wondering if those also tie back to this inherent difference in how the tabs are opened.

Can anyone tell me what the Search feature is doing differently?  Is it something I can add to my _openDocument method so it behaves appropriately?  These aren't showstopper problems, but they are inconveniences to the many users of our product.

Thanks!

------------------------------
Brad Pratt
------------------------------
​
#IBMContentNavigator(ICN)​#DaejaViewONE​​