nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Find more posts tagged with

Accepted answers

Florent_Guillau

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.

All comments

Florent_Guillau

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.