Is it possible for Nuxeo CMIS client to know how long a document has been currently checked-out?

[ron_1]

Most pessimistic locking (check-out/check-in/cancel-check-out) scenarios must plan for the case where a client performs a check-out and then fails to ever either check-in or cancel the check-out. One way to handle this problem is for all clients to be able to track how long a document has been currently checked-out and if it exceeds a certain threshold, cancel the offending check-out and then perform its own check-out.

In CMIS, the PWC has a cmis:creationDate property which would seem to represent the date the PWC was created which is also the checked-out date. This date could be used to implement the scheme described above. In Nuxeo, however, the Live Document is the PWC and therefore its cmis:creationDate does not represent the check-out date. Would it be appropriate for Nuxeo to support the scheme described above by maintaining the checkedOutDate for the Live Document and exposing it as a nuxeo: schema property to CMIS clients?

[Florent_Guillau · Accepted solution]

You make a good point regarding the cmis:creationDate of the PWC. I'm not sure what the spec says about it exactly; even though it probably requires nothing special what you suggest would make more sense.

But we'd have to decide in what schema to store this property and then modify the code accordingly to update it, and map it through the CMIS connector.

[ron_1]

Rather than storing a new property, would it be possible to replace the hierarchy.ischeckedin boolean column with a nullable hierarchy.checkedout date column and derive the isCheckedIn value from the values of columns hierarchy.checkedout and hierarchy.baseversionid?

[Florent_Guillau]

We need an efficient way to verify and query if a document is checked in, so the boolean should probably stay. Anyway what you're suggesting could work but it's not a trivial change.

[ron_1]

How about preserving the hierarchy.isCheckedIn BOOLEAN column and adding a new hierarchy.checkedOut DATE column to be used for this purpose? Since the BOOLEAN isCheckedIn column consumes very little space, there is probably no harm in keeping it even if it is potentially derivable from the other two columns.

[ron_1]

I just stumbled upon your [NXP-8515 comment][1] "In the future we'll lock/unlock when doing checkout/checkin and use the locker". In light of this comment and the fact that [NXP-9260][2] now locks/unlocks when doing checkout/checkin, would it make more sense to use column locks.created for nuxeo

[Florent_Guillau]

Ticket