Can replication\save conflicts be identified in Xpages

Question

If I know a notes document opened in Xpages has created a replication\save conflict duplicate document and then search for the document ID in Xpages then both (or all) the documents are shown in an Xpage set up with a specific Notes view in my application. But is there any way I can tell which one is the parent document and which one(s) are the replication response documents? I need to be able to see this on the Xpages front end and not just in the Notes database backend.

Answer 1

If you create a view with @IsAvailable($Conflict) as the selection formula, you can identify conflicts. They have a $REF field which maps to the parent document.

Because XPages allows us to have multiple datasources on an XPage, it should be feasible to open the conflict have dominoDocument datasources for the conflict and the parent document (the non-conflict).

Answer 2

If your view has the option 'Show response documents in a hierarchy' then your parent document comes always first and right after it all the replication conflicts. You can show the replication conflicts this way:

<xp:viewPanel
    value="#{view1}"
    id="viewPanel1" 
    var="rowData">
    ...
    <xp:viewColumn
        columnName="yourColumnName"
        id="viewColumn2"
        value="#{javascript:
            if (rowData.getDocument().hasItem('$Conflict')) {
                var parentId = rowData.getDocument().getItemValue('$REF');
                return '[Replication ot Save Conflict]';
            }
            return rowData.getColumnValue('yourColumnName')
        }">
        <xp:this.facets>
            <xp:viewColumnHeader
                value="Unid"
                xp:key="header"
                id="viewColumnHeader2">
            </xp:viewColumnHeader>
        </xp:this.facets>
    </xp:viewColumn>
</xp:viewPanel>

Orphan replication conflict documents with deleted parent document don't show up in this kind of view.

If your view has not the option 'Show response documents in a hierarchy' set then all replication conflicts would be visible even the orphans. Documents are sorted by the column values so the replication conflicts wouldn't be necessary right beneath the parents document. In this case you might want to show the parent's DocumentUniqueID in addition with the help of parentId variable.

Answer 3

Although previous answers will help, they complicate everything at page level. Get rid of conflicts in their source - so XPage or background code doesn't need to.

In our applications every view used for XPages has selection formula enriched with

& !@IsAvailable( $Conflict )

That way no matter what code (datasource, component, SSJS, Java, @Formula) in XPage does not need to handle conflicts.

Edited to answer your question:

In adition to above, you can have special view with conflicts only (selection of @isAvailable( $Conflict )) sorted by @Text( $REF ) column. You are not able to show any other data for conflict documents.

Then, you can add column that will lookup whether document with specific UNID has any conflict documents and highlight them, show conflict count, or something else.

My two cents though - conflict resolving in Notes client is much clever idea.

Answer 4

All these responses are great but in the end why are conflicts getting generated? There should be logic in the design so that a minimal group of people can edit a document at any one time. If all your users are editor level then re-think your application. Most users should be author access and the use of authors field defines who can edit that document, which might change depending on the workflow status.