Does the CollectionSpace database keep a history of what edits were made to records and by whom? The record itself has a "Created" and "Modified" labels in the UI, but it doesn't seem to go back more than the most recent edit. If this data does exist in the database, how do I surface it in the UI? Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

The closest thing that I can think of to this - that's built into (e.g. not added onto) CollectionSpace - is its versioning capabilities. Via simple configuration, you can designate one or more record types to be 'versioned.' Each time a record is saved, the current version is displayed and the previous version(s) are archived. Archived versions can be identified, and even - with some, perhaps considerable, effort - retrieved, via database queries/reporting. This uses the following Nuxeo feature: https://doc.nuxeo.com/display/NXDOC/Versioning Here's how versioned records are identified, via a query to Nuxeo's 'hierarchy' table; https://issues.collectionspace.org/browse/CSPACE-6334?focusedCommentId=44679&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44679 Instances of a record, all sharing the same identifier (CSID), where the value of the 'isversion' field is 'true' are previous versions, and their ascending major and minor version numbers are captured in two other fields. I don't recall if data is kept for which user created any particular version, or when those versions are time stamped. If not, this relegates this approach to data recovery, and some potential use in forensics, but not to basic audit trail capabilities. There's an example of a versioned record type, and how it's configured, in the demonstration ("out of the box") instance of CollectionSpace. In the Lifesci tenant, Location/Movement/Inventory records are versioned, as a means of demonstrating this capability: https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-procedure-movement.xml On Tue, Sep 29, 2015 at 6:02 PM, Peter Murray <pmurray@chillco.com> wrote: > Does the CollectionSpace database keep a history of what edits were made > to records and by whom? The record itself has a "Created" and "Modified" > labels in the UI, but it doesn't seem to go back more than the most recent > edit. If this data does exist in the database, how do I surface it in the > UI? > > > Peter > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >

Thanks, Aron. "versioning" was the term I was trying to think of. To colleagues from the UC Botanical Garden: are you actively using versioning on some or all of your records? Are you showing the version history to your users? Peter > On Sep 29, 2015, at 9:24 PM, Aron Roberts <aron@socrates.berkeley.edu> wrote: > > The closest thing that I can think of to this - that's built into (e.g. not added onto) CollectionSpace - is its versioning capabilities. > > Via simple configuration, you can designate one or more record types to be 'versioned.' Each time a record is saved, the current version is displayed and the previous version(s) are archived. Archived versions can be identified, and even - with some, perhaps considerable, effort - retrieved, via database queries/reporting. This uses the following Nuxeo feature: > > https://doc.nuxeo.com/display/NXDOC/Versioning <https://doc.nuxeo.com/display/NXDOC/Versioning> > > Here's how versioned records are identified, via a query to Nuxeo's 'hierarchy' table; > > https://issues.collectionspace.org/browse/CSPACE-6334?focusedCommentId=44679&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44679 <https://issues.collectionspace.org/browse/CSPACE-6334?focusedCommentId=44679&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44679> > > Instances of a record, all sharing the same identifier (CSID), where the value of the 'isversion' field is 'true' are previous versions, and their ascending major and minor version numbers are captured in two other fields. > > I don't recall if data is kept for which user created any particular version, or when those versions are time stamped. If not, this relegates this approach to data recovery, and some potential use in forensics, but not to basic audit trail capabilities. > > There's an example of a versioned record type, and how it's configured, in the demonstration ("out of the box") instance of CollectionSpace. In the Lifesci tenant, Location/Movement/Inventory records are versioned, as a means of demonstrating this capability: > > https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-procedure-movement.xml <https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-procedure-movement.xml> > > On Tue, Sep 29, 2015 at 6:02 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: > Does the CollectionSpace database keep a history of what edits were made to records and by whom? The record itself has a "Created" and "Modified" labels in the UI, but it doesn't seem to go back more than the most recent edit. If this data does exist in the database, how do I surface it in the UI? > > > Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

Hi Peter, I’ll jump in here, and we’ll see if our UC Botanical Garden colleagues add information. We used the versioning feature that Aron nicely described to replace a capability they had in their legacy system called “Accession History”. Basically, we are storing versions of their Movement records (the Location/Movement/Inventory transactions in CollectionSpace core). This keeps the more detailed history of their location information. They can’t see that history in the UI, but we have at least one report that explicitly shows the different version in an appropriate chronological order https://github.com/cspace-deployment/Tools/blob/master/reports/botgarden/ucbgAccessionHistory.jrxml <https://github.com/cspace-deployment/Tools/blob/master/reports/botgarden/ucbgAccessionHistory.jrxml> The corollary though is that for other reports we have to exclude the “versioned” records because in these other reports they just want to know where the plant is alive in the garden NOW. The notion of an audit trail in CSpace is one that comes up not infrequently. Can you describe a bit more about what you’re trying to do (or being asked to do)? We even recently had a discussion about setting up some database triggers outside CollectionSpace itself that might give us some capabilities in this area. Thanks, Chris > On Sep 29, 2015, at 7:13 PM, Peter Murray <pmurray@chillco.com> wrote: > > Thanks, Aron. "versioning" was the term I was trying to think of. > > To colleagues from the UC Botanical Garden: are you actively using versioning on some or all of your records? Are you showing the version history to your users? > > > Peter > > >> On Sep 29, 2015, at 9:24 PM, Aron Roberts <aron@socrates.berkeley.edu <mailto:aron@socrates.berkeley.edu>> wrote: >> >> The closest thing that I can think of to this - that's built into (e.g. not added onto) CollectionSpace - is its versioning capabilities. >> >> Via simple configuration, you can designate one or more record types to be 'versioned.' Each time a record is saved, the current version is displayed and the previous version(s) are archived. Archived versions can be identified, and even - with some, perhaps considerable, effort - retrieved, via database queries/reporting. This uses the following Nuxeo feature: >> >> https://doc.nuxeo.com/display/NXDOC/Versioning <https://doc.nuxeo.com/display/NXDOC/Versioning> >> >> Here's how versioned records are identified, via a query to Nuxeo's 'hierarchy' table; >> >> https://issues.collectionspace.org/browse/CSPACE-6334?focusedCommentId=44679&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44679 <https://issues.collectionspace.org/browse/CSPACE-6334?focusedCommentId=44679&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44679> >> >> Instances of a record, all sharing the same identifier (CSID), where the value of the 'isversion' field is 'true' are previous versions, and their ascending major and minor version numbers are captured in two other fields. >> >> I don't recall if data is kept for which user created any particular version, or when those versions are time stamped. If not, this relegates this approach to data recovery, and some potential use in forensics, but not to basic audit trail capabilities. >> >> There's an example of a versioned record type, and how it's configured, in the demonstration ("out of the box") instance of CollectionSpace. In the Lifesci tenant, Location/Movement/Inventory records are versioned, as a means of demonstrating this capability: >> >> https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-procedure-movement.xml <https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-procedure-movement.xml> >> >> On Tue, Sep 29, 2015 at 6:02 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >> Does the CollectionSpace database keep a history of what edits were made to records and by whom? The record itself has a "Created" and "Modified" labels in the UI, but it doesn't seem to go back more than the most recent edit. If this data does exist in the database, how do I surface it in the UI? >> >> >> Peter > > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Hi Chris, At the moment the functionality I'm trying to replicate (and the data I'm aiming not to lose) is the fact that a record was updated by a user at a particular time. (Specifically, I have a record type, a boolean for whether the record was new, a timestamp, the login ID of the person making the change, and a link to the unique record number.) It looks like I have this history for eight record types (including Accessions and Cataloging records). The ability to view this edit history is in the application itself, but a Jasper Reports query might be a good substitute. Nuxeos's version history is a little overkill for that, but depending on the database overhead that might be the path of least resistance. Other thoughts? Peter > On Sep 30, 2015, at 12:14 AM, Chris Hoffman <chris_h@berkeley.edu> wrote: > > Hi Peter, I’ll jump in here, and we’ll see if our UC Botanical Garden colleagues add information. We used the versioning feature that Aron nicely described to replace a capability they had in their legacy system called “Accession History”. Basically, we are storing versions of their Movement records (the Location/Movement/Inventory transactions in CollectionSpace core). This keeps the more detailed history of their location information. They can’t see that history in the UI, but we have at least one report that explicitly shows the different version in an appropriate chronological order > https://github.com/cspace-deployment/Tools/blob/master/reports/botgarden/ucbgAccessionHistory.jrxml <https://github.com/cspace-deployment/Tools/blob/master/reports/botgarden/ucbgAccessionHistory.jrxml> > > The corollary though is that for other reports we have to exclude the “versioned” records because in these other reports they just want to know where the plant is alive in the garden NOW. > > The notion of an audit trail in CSpace is one that comes up not infrequently. Can you describe a bit more about what you’re trying to do (or being asked to do)? We even recently had a discussion about setting up some database triggers outside CollectionSpace itself that might give us some capabilities in this area. > > Thanks, > Chris > > >> On Sep 29, 2015, at 7:13 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >> >> Thanks, Aron. "versioning" was the term I was trying to think of. >> >> To colleagues from the UC Botanical Garden: are you actively using versioning on some or all of your records? Are you showing the version history to your users? >> >> >> Peter >> >> >>> On Sep 29, 2015, at 9:24 PM, Aron Roberts <aron@socrates.berkeley.edu <mailto:aron@socrates.berkeley.edu>> wrote: >>> >>> The closest thing that I can think of to this - that's built into (e.g. not added onto) CollectionSpace - is its versioning capabilities. >>> >>> Via simple configuration, you can designate one or more record types to be 'versioned.' Each time a record is saved, the current version is displayed and the previous version(s) are archived. Archived versions can be identified, and even - with some, perhaps considerable, effort - retrieved, via database queries/reporting. This uses the following Nuxeo feature: >>> >>> https://doc.nuxeo.com/display/NXDOC/Versioning <https://doc.nuxeo.com/display/NXDOC/Versioning> >>> >>> Here's how versioned records are identified, via a query to Nuxeo's 'hierarchy' table; >>> >>> https://issues.collectionspace.org/browse/CSPACE-6334?focusedCommentId=44679&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44679 <https://issues.collectionspace.org/browse/CSPACE-6334?focusedCommentId=44679&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44679> >>> >>> Instances of a record, all sharing the same identifier (CSID), where the value of the 'isversion' field is 'true' are previous versions, and their ascending major and minor version numbers are captured in two other fields. >>> >>> I don't recall if data is kept for which user created any particular version, or when those versions are time stamped. If not, this relegates this approach to data recovery, and some potential use in forensics, but not to basic audit trail capabilities. >>> >>> There's an example of a versioned record type, and how it's configured, in the demonstration ("out of the box") instance of CollectionSpace. In the Lifesci tenant, Location/Movement/Inventory records are versioned, as a means of demonstrating this capability: >>> >>> https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-procedure-movement.xml <https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-procedure-movement.xml> >>> >>> On Tue, Sep 29, 2015 at 6:02 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >>> Does the CollectionSpace database keep a history of what edits were made to records and by whom? The record itself has a "Created" and "Modified" labels in the UI, but it doesn't seem to go back more than the most recent edit. If this data does exist in the database, how do I surface it in the UI? >>> >>> >>> Peter >> >> -- >> Peter Murray >> Dev/Ops Lead and Project Manager >> Cherry Hill Company >> >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org <mailto:Talk@lists.collectionspace.org> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

Peter, Yes, the "audit trail" functionality was planned as part of CSpace but was not (has not yet?) been implemented. The trail of work so far on this can be seen in the wiki and in JIRA, e.g. https://issues.collectionspace.org/browse/CSPACE-204 https://issues.collectionspace.org/browse/CSPACE-2407 etc. The result of using nuxeo versioning to track changes in records has been mixed. As Chris and Aron pointed out, nuxeo versioning capabilities were used to track "accession history" for UCBG. However, the history of an accession cannot be viewed / searched directly in the UI -- it is only available as a JasperSoft report for a single accession at a time. And writing the queries for this functionality and other functionalities has been complicated by this choice since report writers now *must* take account of the versions when writing their SQL. I'd recommend against using this built-in nuxeo functionality without a thorough understanding of what you're getting in to. The "database triggers" idea Chris mentioned is pretty intriguing and might not be too difficult. In principle, one need only add triggers to the various *_common tables to write out some details when records are modified. Speculative, though! Indeed, PAHMA has written a "change monitoring system" around nightly queries which look for changes in certain tables within a date range -- alas, these changes can't be linked to particular users, as that info simply isn't saved in the database... John On Wed, Sep 30, 2015 at 7:46 AM, Peter Murray <pmurray@chillco.com> wrote: > Hi Chris, > > At the moment the functionality I'm trying to replicate (and the data I'm > aiming not to lose) is the fact that a record was updated by a user at a > particular time. (Specifically, I have a record type, a boolean for > whether the record was new, a timestamp, the login ID of the person making > the change, and a link to the unique record number.) It looks like I have > this history for eight record types (including Accessions and Cataloging > records). The ability to view this edit history is in the application > itself, but a Jasper Reports query might be a good substitute. Nuxeos's > version history is a little overkill for that, but depending on the > database overhead that might be the path of least resistance. > > Other thoughts? > > > Peter > > On Sep 30, 2015, at 12:14 AM, Chris Hoffman <chris_h@berkeley.edu> wrote: > > Hi Peter, I’ll jump in here, and we’ll see if our UC Botanical Garden > colleagues add information. We used the versioning feature that Aron nicely > described to replace a capability they had in their legacy system called > “Accession History”. Basically, we are storing versions of their Movement > records (the Location/Movement/Inventory transactions in CollectionSpace > core). This keeps the more detailed history of their location > information. They can’t see that history in the UI, but we have at least > one report that explicitly shows the different version in an appropriate > chronological order > > https://github.com/cspace-deployment/Tools/blob/master/reports/botgarden/ucbgAccessionHistory.jrxml > > The corollary though is that for other reports we have to exclude the > “versioned” records because in these other reports they just want to know > where the plant is alive in the garden NOW. > > The notion of an audit trail in CSpace is one that comes up not > infrequently. Can you describe a bit more about what you’re trying to do > (or being asked to do)? We even recently had a discussion about setting up > some database triggers outside CollectionSpace itself that might give us > some capabilities in this area. > > Thanks, > Chris > > > On Sep 29, 2015, at 7:13 PM, Peter Murray <pmurray@chillco.com> wrote: > > Thanks, Aron. "versioning" was the term I was trying to think of. > > To colleagues from the UC Botanical Garden: are you actively using > versioning on some or all of your records? Are you showing the version > history to your users? > > > Peter > > > On Sep 29, 2015, at 9:24 PM, Aron Roberts <aron@socrates.berkeley.edu> > wrote: > > The closest thing that I can think of to this - that's built into (e.g. > not added onto) CollectionSpace - is its versioning capabilities. > > Via simple configuration, you can designate one or more record types to be > 'versioned.' Each time a record is saved, the current version is displayed > and the previous version(s) are archived. Archived versions can be > identified, and even - with some, perhaps considerable, effort - retrieved, > via database queries/reporting. This uses the following Nuxeo feature: > > https://doc.nuxeo.com/display/NXDOC/Versioning > > Here's how versioned records are identified, via a query to Nuxeo's > 'hierarchy' table; > > > https://issues.collectionspace.org/browse/CSPACE-6334?focusedCommentId=44679&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44679 > > Instances of a record, all sharing the same identifier (CSID), where the > value of the 'isversion' field is 'true' are previous versions, and their > ascending major and minor version numbers are captured in two other fields. > > I don't recall if data is kept for which user created any particular > version, or when those versions are time stamped. If not, this relegates > this approach to data recovery, and some potential use in forensics, but > not to basic audit trail capabilities. > > There's an example of a versioned record type, and how it's configured, in > the demonstration ("out of the box") instance of CollectionSpace. In the > Lifesci tenant, Location/Movement/Inventory records are versioned, as a > means of demonstrating this capability: > > > https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-procedure-movement.xml > > On Tue, Sep 29, 2015 at 6:02 PM, Peter Murray <pmurray@chillco.com> wrote: > >> Does the CollectionSpace database keep a history of what edits were made >> to records and by whom? The record itself has a "Created" and "Modified" >> labels in the UI, but it doesn't seem to go back more than the most recent >> edit. If this data does exist in the database, how do I surface it in the >> UI? >> >> >> Peter > > > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

Thanks for the pointers into the CSpace tickets and user stories. There is a wide variety of functionality there, and what SDMoM is seeking is just a part of that audit trail functionality. I'm not sure what we'll end up doing at this point, but the database triggers and the batch change-monitoring-system are interesting work-arounds. PEter > On Sep 30, 2015, at 11:35 AM, John B. LOWE <jblowe@berkeley.edu> wrote: > > Peter, > > Yes, the "audit trail" functionality was planned as part of CSpace but was not (has not yet?) been implemented. The trail of work so far on this can be seen in the wiki and in JIRA, e.g. > > https://issues.collectionspace.org/browse/CSPACE-204 <https://issues.collectionspace.org/browse/CSPACE-204> > https://issues.collectionspace.org/browse/CSPACE-2407 <https://issues.collectionspace.org/browse/CSPACE-2407> > etc. > > The result of using nuxeo versioning to track changes in records has been mixed. As Chris and Aron pointed out, nuxeo versioning capabilities were used to track "accession history" for UCBG. However, the history of an accession cannot be viewed / searched directly in the UI -- it is only available as a JasperSoft report for a single accession at a time. And writing the queries for this functionality and other functionalities has been complicated by this choice since report writers now *must* take account of the versions when writing their SQL. I'd recommend against using this built-in nuxeo functionality without a thorough understanding of what you're getting in to. > > The "database triggers" idea Chris mentioned is pretty intriguing and might not be too difficult. In principle, one need only add triggers to the various *_common tables to write out some details when records are modified. Speculative, though! > > Indeed, PAHMA has written a "change monitoring system" around nightly queries which look for changes in certain tables within a date range -- alas, these changes can't be linked to particular users, as that info simply isn't saved in the database... > > John > > On Wed, Sep 30, 2015 at 7:46 AM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: > Hi Chris, > > At the moment the functionality I'm trying to replicate (and the data I'm aiming not to lose) is the fact that a record was updated by a user at a particular time. (Specifically, I have a record type, a boolean for whether the record was new, a timestamp, the login ID of the person making the change, and a link to the unique record number.) It looks like I have this history for eight record types (including Accessions and Cataloging records). The ability to view this edit history is in the application itself, but a Jasper Reports query might be a good substitute. Nuxeos's version history is a little overkill for that, but depending on the database overhead that might be the path of least resistance. > > Other thoughts? > > > Peter > >> On Sep 30, 2015, at 12:14 AM, Chris Hoffman <chris_h@berkeley.edu <mailto:chris_h@berkeley.edu>> wrote: >> >> Hi Peter, I’ll jump in here, and we’ll see if our UC Botanical Garden colleagues add information. We used the versioning feature that Aron nicely described to replace a capability they had in their legacy system called “Accession History”. Basically, we are storing versions of their Movement records (the Location/Movement/Inventory transactions in CollectionSpace core). This keeps the more detailed history of their location information. They can’t see that history in the UI, but we have at least one report that explicitly shows the different version in an appropriate chronological order >> https://github.com/cspace-deployment/Tools/blob/master/reports/botgarden/ucbgAccessionHistory.jrxml <https://github.com/cspace-deployment/Tools/blob/master/reports/botgarden/ucbgAccessionHistory.jrxml> >> >> The corollary though is that for other reports we have to exclude the “versioned” records because in these other reports they just want to know where the plant is alive in the garden NOW. >> >> The notion of an audit trail in CSpace is one that comes up not infrequently. Can you describe a bit more about what you’re trying to do (or being asked to do)? We even recently had a discussion about setting up some database triggers outside CollectionSpace itself that might give us some capabilities in this area. >> >> Thanks, >> Chris >> >> >>> On Sep 29, 2015, at 7:13 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >>> >>> Thanks, Aron. "versioning" was the term I was trying to think of. >>> >>> To colleagues from the UC Botanical Garden: are you actively using versioning on some or all of your records? Are you showing the version history to your users? >>> >>> >>> Peter >>> >>> >>>> On Sep 29, 2015, at 9:24 PM, Aron Roberts <aron@socrates.berkeley.edu <mailto:aron@socrates.berkeley.edu>> wrote: >>>> >>>> The closest thing that I can think of to this - that's built into (e.g. not added onto) CollectionSpace - is its versioning capabilities. >>>> >>>> Via simple configuration, you can designate one or more record types to be 'versioned.' Each time a record is saved, the current version is displayed and the previous version(s) are archived. Archived versions can be identified, and even - with some, perhaps considerable, effort - retrieved, via database queries/reporting. This uses the following Nuxeo feature: >>>> >>>> https://doc.nuxeo.com/display/NXDOC/Versioning <https://doc.nuxeo.com/display/NXDOC/Versioning> >>>> >>>> Here's how versioned records are identified, via a query to Nuxeo's 'hierarchy' table; >>>> >>>> https://issues.collectionspace.org/browse/CSPACE-6334?focusedCommentId=44679&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44679 <https://issues.collectionspace.org/browse/CSPACE-6334?focusedCommentId=44679&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44679> >>>> >>>> Instances of a record, all sharing the same identifier (CSID), where the value of the 'isversion' field is 'true' are previous versions, and their ascending major and minor version numbers are captured in two other fields. >>>> >>>> I don't recall if data is kept for which user created any particular version, or when those versions are time stamped. If not, this relegates this approach to data recovery, and some potential use in forensics, but not to basic audit trail capabilities. >>>> >>>> There's an example of a versioned record type, and how it's configured, in the demonstration ("out of the box") instance of CollectionSpace. In the Lifesci tenant, Location/Movement/Inventory records are versioned, as a means of demonstrating this capability: >>>> >>>> https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-procedure-movement.xml <https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/resources/tenants/lifesci/lifesci-procedure-movement.xml> >>>> >>>> On Tue, Sep 29, 2015 at 6:02 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >>>> Does the CollectionSpace database keep a history of what edits were made to records and by whom? The record itself has a "Created" and "Modified" labels in the UI, but it doesn't seem to go back more than the most recent edit. If this data does exist in the database, how do I surface it in the UI? >>>> >>>> >>>> Peter >>> >>> -- >>> Peter Murray >>> Dev/Ops Lead and Project Manager >>> Cherry Hill Company >>> >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org <mailto:Talk@lists.collectionspace.org> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org <http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org> -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company