talk@lists.collectionspace.org
WE HAVE SUNSET THIS LISTSERV - Join us at collectionspace@lyrasislists.org
View all threadsimporting movement records as 'locked'
After changing the <lifecycle-policy> text to cs_locking
in service-document.xml, I'm still seeing movement records imported with
the normal default lifecycle policy and not in a locked state. Is there
something I may be missing? I also attempted to manipulate the
<workflowState> value in the xml file being imported, but got an error.
Thanks,
- Jesse
Hi Jesse,
On Thu, Jun 6, 2013 at 10:10 AM, Jesse Martinez mjesse@gmail.com wrote:
After changing the <lifecycle-policy> text to cs_locking in
service-document.xml, I'm still seeing movement records imported with the
normal default lifecycle policy and not in a locked state. Is there
something I may be missing? I also attempted to manipulate the
<workflowState> value in the xml file being imported, but got an error.
That would appear to be this known issue:
"Imported records are always (incorrectly?) assigned to the default
workflow lifecycle"
http://issues.collectionspace.org/browse/CSPACE-5306
At present, one workaround would be to use Services REST API calls
to change workflow state for your imported Movement records:
As a second workaround (untried by me), it might also be possible to
simply use a SQL UPDATE call to change the workflow state of the
relevant records, which are stored as simple strings in the misc
table, lifecyclestate column, in the nuxeo database. If you have only
CSIDs of your imported records, you'll need to 'walk up' a level in
the hierarchy table to get the Nuxeo ID values, which which you can
identify the relevant rows.
Aron
--
Thanks,
- Jesse
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
On Thu, Jun 6, 2013 at 11:30 AM, Aron Roberts
aron@socrates.berkeley.edu wrote:
As a second workaround (untried by me), it might also be possible to
simply use a SQL UPDATE call to change the workflow state of the
relevant records, which are stored as simple strings in the misc
table, lifecyclestate column, in the nuxeo database. If you have only
CSIDs of your imported records, you'll need to 'walk up' a level in
the hierarchy table to get the Nuxeo ID values, which which you can
identify the relevant rows.
A postscript: you'd also likely need to update the lifecyclepolicy
column's value to 'cs_locking', on each row on which you also updated
the lifecyclestate column's value to 'locked'.
Aron
Aron
--
Thanks,
- Jesse
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Thanks, Aron, making a second PUT command did the trick.
- Jesse
On Thu, Jun 6, 2013 at 2:30 PM, Aron Roberts aron@socrates.berkeley.eduwrote:
Hi Jesse,
On Thu, Jun 6, 2013 at 10:10 AM, Jesse Martinez mjesse@gmail.com wrote:
After changing the <lifecycle-policy> text to cs_locking in
service-document.xml, I'm still seeing movement records imported with the
normal default lifecycle policy and not in a locked state. Is there
something I may be missing? I also attempted to manipulate the
<workflowState> value in the xml file being imported, but got an error.
That would appear to be this known issue:
"Imported records are always (incorrectly?) assigned to the default
workflow lifecycle"
http://issues.collectionspace.org/browse/CSPACE-5306
At present, one workaround would be to use Services REST API calls
to change workflow state for your imported Movement records:
As a second workaround (untried by me), it might also be possible to
simply use a SQL UPDATE call to change the workflow state of the
relevant records, which are stored as simple strings in the misc
table, lifecyclestate column, in the nuxeo database. If you have only
CSIDs of your imported records, you'll need to 'walk up' a level in
the hierarchy table to get the Nuxeo ID values, which which you can
identify the relevant rows.
Aron
--
One following thought ... if you check via SQL:
nuxeo=# select * from misc where lifecyclestate='locked';
is the value of the lifecyclepolicy column on that row, representing
the just-imported record, still 'default'? If so, you may want to
manually update that value as well; e.g.
update misc set lifecyclepolicy='cs_locking' where lifecyclestate='locked';
That way, any enforcement of transitions between lifecycle states for
that record will be respected; e.g., if that lifecycle policy
prohibits records from being transitioned out of the 'locked' state.
On Thu, Jun 6, 2013 at 1:53 PM, Jesse Martinez mjesse@gmail.com wrote:
Thanks, Aron, making a second PUT command did the trick.
- Jesse
On Thu, Jun 6, 2013 at 2:30 PM, Aron Roberts aron@socrates.berkeley.edu
wrote:
Hi Jesse,
On Thu, Jun 6, 2013 at 10:10 AM, Jesse Martinez mjesse@gmail.com wrote:
After changing the <lifecycle-policy> text to cs_locking in
service-document.xml, I'm still seeing movement records imported with
the
normal default lifecycle policy and not in a locked state. Is there
something I may be missing? I also attempted to manipulate the
<workflowState> value in the xml file being imported, but got an error.
That would appear to be this known issue:
"Imported records are always (incorrectly?) assigned to the default
workflow lifecycle"
http://issues.collectionspace.org/browse/CSPACE-5306
At present, one workaround would be to use Services REST API calls
to change workflow state for your imported Movement records:
As a second workaround (untried by me), it might also be possible to
simply use a SQL UPDATE call to change the workflow state of the
relevant records, which are stored as simple strings in the misc
table, lifecyclestate column, in the nuxeo database. If you have only
CSIDs of your imported records, you'll need to 'walk up' a level in
the hierarchy table to get the Nuxeo ID values, which which you can
identify the relevant rows.
Aron
--
Thanks,
- Jesse
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org