SDMoM has a question about the data that appears on the search results screen and whether it can include the identifier(s) for related record(s). For instance, what appears in the "Summary" column for Condition Check records by default is the Condition vocabulary term, so what you get is a column with the Condition Check record identifier, a column of Conditions ("Good", "Fair", "Poor", etc.), a column for the record type and a column for when the record was last updated. What would be _really_ nice is if the Summary column also contained the identifiers for the related objects, so it would look something like this: ID Number Summary Record Type Updated At CC.PP.1880 1971.1.1, None condition check 2015-11-19T03:28:52.337Z Note the addition of "1971.1.1" in the summary column. (FYI, in this example "CC.PP.1880" identifies a particular row in a table of migrated PastPerfect data.) Is this possible? Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

For starters, it might be worth looking at Ray's notes here, on changing which field appears in the Summary column in search results: https://issues.collectionspace.org/browse/UCJEPS-106 This particular case involved a field in an extension schema, so it's useful as an illustration of how to specify the field's schema, as well. Usual disclaimers apply: this work dates back to 2012, and I don't know for certain whether it reflects current configuration practices. But hopefully this might get you started ... On Mon, Nov 23, 2015 at 10:55 AM, Peter Murray <pmurray@chillco.com> wrote: > SDMoM has a question about the data that appears on the search results > screen and whether it can include the identifier(s) for related record(s). > For instance, what appears in the "Summary" column for Condition Check > records by default is the Condition vocabulary term, so what you get is a > column with the Condition Check record identifier, a column of Conditions > ("Good", "Fair", "Poor", etc.), a column for the record type and a column > for when the record was last updated. What would be _really_ nice is if > the Summary column also contained the identifiers for the related objects, > so it would look something like this: > > ID Number Summary Record Type Updated At > CC.PP.1880 1971.1.1, None condition check > 2015-11-19T03:28:52.337Z > > Note the addition of "1971.1.1" in the summary column. (FYI, in this > example "CC.PP.1880" identifies a particular row in a table of migrated > PastPerfect data.) > > Is this possible? > > > 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 Peter, You've got two problems there. The first is that CSpace doesn't let you have more than one field appear in the summary column. The strategy I've used to work around that is to create a field that is computed from the values of other fields, and configure that computed field to be the summary. The other problem is that for a given condition check record, its related collectionobjects aren't stored in a field on the condition check; there are separate relation records that contain this information. You would have to denormalize that data somehow, so that it's available on the condition check. The way I would do it is to write a Nuxeo event handler that listens for creates, updates, and deletes of relation records, and if the relation is between a condition check and a collectionobject, updates a field on the condition check. An example of something similar would be the code that sets the computed current location on collectionobjects. So this is a non-trivial amount of work. Ray On Mon, Nov 23, 2015 at 12:06 PM, Aron Roberts <aron@socrates.berkeley.edu> wrote: > For starters, it might be worth looking at Ray's notes here, on changing > which field appears in the Summary column in search results: > > https://issues.collectionspace.org/browse/UCJEPS-106 > > This particular case involved a field in an extension schema, so it's > useful as an illustration of how to specify the field's schema, as well. > > Usual disclaimers apply: this work dates back to 2012, and I don't know > for certain whether it reflects current configuration practices. But > hopefully this might get you started ... > > > On Mon, Nov 23, 2015 at 10:55 AM, Peter Murray <pmurray@chillco.com> > wrote: > >> SDMoM has a question about the data that appears on the search results >> screen and whether it can include the identifier(s) for related record(s). >> For instance, what appears in the "Summary" column for Condition Check >> records by default is the Condition vocabulary term, so what you get is a >> column with the Condition Check record identifier, a column of Conditions >> ("Good", "Fair", "Poor", etc.), a column for the record type and a column >> for when the record was last updated. What would be _really_ nice is if >> the Summary column also contained the identifiers for the related objects, >> so it would look something like this: >> >> ID Number Summary Record Type Updated At >> CC.PP.1880 1971.1.1, None condition check >> 2015-11-19T03:28:52.337Z >> >> Note the addition of "1971.1.1" in the summary column. (FYI, in this >> example "CC.PP.1880" identifies a particular row in a table of migrated >> PastPerfect data.) >> >> Is this possible? >> >> >> 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 >> > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

Thanks, Ray -- I hadn't thought of using the computed field functionality; patching into the Nuxeo event handler is an interesting idea. Definitely non-trivial, but would be a useful path to follow. I had a feeling that it wasn't functionality that could be done out-of-the-box. Peter > On Nov 23, 2015, at 6:22 PM, Ray Lee <rhlee@berkeley.edu> wrote: > > Hi Peter, > You've got two problems there. The first is that CSpace doesn't let you have more than one field appear in the summary column. The strategy I've used to work around that is to create a field that is computed from the values of other fields, and configure that computed field to be the summary. The other problem is that for a given condition check record, its related collectionobjects aren't stored in a field on the condition check; there are separate relation records that contain this information. You would have to denormalize that data somehow, so that it's available on the condition check. The way I would do it is to write a Nuxeo event handler that listens for creates, updates, and deletes of relation records, and if the relation is between a condition check and a collectionobject, updates a field on the condition check. An example of something similar would be the code that sets the computed current location on collectionobjects. So this is a non-trivial amount of work. > > Ray > > > On Mon, Nov 23, 2015 at 12:06 PM, Aron Roberts <aron@socrates.berkeley.edu <mailto:aron@socrates.berkeley.edu>> wrote: > For starters, it might be worth looking at Ray's notes here, on changing which field appears in the Summary column in search results: > > https://issues.collectionspace.org/browse/UCJEPS-106 <https://issues.collectionspace.org/browse/UCJEPS-106> > > This particular case involved a field in an extension schema, so it's useful as an illustration of how to specify the field's schema, as well. > > Usual disclaimers apply: this work dates back to 2012, and I don't know for certain whether it reflects current configuration practices. But hopefully this might get you started ... > > > On Mon, Nov 23, 2015 at 10:55 AM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: > SDMoM has a question about the data that appears on the search results screen and whether it can include the identifier(s) for related record(s). For instance, what appears in the "Summary" column for Condition Check records by default is the Condition vocabulary term, so what you get is a column with the Condition Check record identifier, a column of Conditions ("Good", "Fair", "Poor", etc.), a column for the record type and a column for when the record was last updated. What would be _really_ nice is if the Summary column also contained the identifiers for the related objects, so it would look something like this: > > ID Number Summary Record Type Updated At > CC.PP.1880 1971.1.1, None condition check 2015-11-19T03:28:52.337Z > > Note the addition of "1971.1.1" in the summary column. (FYI, in this example "CC.PP.1880" identifies a particular row in a table of migrated PastPerfect data.) > > Is this possible? > > > Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

Thanks, Ray - really appreciate your picking up on these aspects of Peter's task! Peter, the code that Ray referred to is here: https://github.com/collectionspace/services/tree/master/3rdparty/nuxeo/nuxeo-platform-listener/updateobjectlocationonmove It maintains a (denormalized) value in the Cataloging record that tracks the object's current location, based on its related Location/Movement/Inventory records over time. You might be able to appropriate much of that code for maintaining information on the object within a condition check; the pattern might be pretty similar. On Tue, Nov 24, 2015 at 7:58 AM, Peter Murray <pmurray@chillco.com> wrote: > Thanks, Ray -- I hadn't thought of using the computed field functionality; > patching into the Nuxeo event handler is an interesting idea. Definitely > non-trivial, but would be a useful path to follow. I had a feeling that it > wasn't functionality that could be done out-of-the-box. > > > Peter > > On Nov 23, 2015, at 6:22 PM, Ray Lee <rhlee@berkeley.edu> wrote: > > Hi Peter, > You've got two problems there. The first is that CSpace doesn't let you > have more than one field appear in the summary column. The strategy I've > used to work around that is to create a field that is computed from the > values of other fields, and configure that computed field to be the > summary. The other problem is that for a given condition check record, its > related collectionobjects aren't stored in a field on the condition check; > there are separate relation records that contain this information. You > would have to denormalize that data somehow, so that it's available on the > condition check. The way I would do it is to write a Nuxeo event handler > that listens for creates, updates, and deletes of relation records, and if > the relation is between a condition check and a collectionobject, updates a > field on the condition check. An example of something similar would be the > code that sets the computed current location on collectionobjects. So this > is a non-trivial amount of work. > > Ray > > > On Mon, Nov 23, 2015 at 12:06 PM, Aron Roberts <aron@socrates.berkeley.edu > > wrote: > >> For starters, it might be worth looking at Ray's notes here, on changing >> which field appears in the Summary column in search results: >> >> https://issues.collectionspace.org/browse/UCJEPS-106 >> >> This particular case involved a field in an extension schema, so it's >> useful as an illustration of how to specify the field's schema, as well. >> >> Usual disclaimers apply: this work dates back to 2012, and I don't know >> for certain whether it reflects current configuration practices. But >> hopefully this might get you started ... >> >> >> On Mon, Nov 23, 2015 at 10:55 AM, Peter Murray <pmurray@chillco.com> >> wrote: >> >>> SDMoM has a question about the data that appears on the search results >>> screen and whether it can include the identifier(s) for related record(s). >>> For instance, what appears in the "Summary" column for Condition Check >>> records by default is the Condition vocabulary term, so what you get is a >>> column with the Condition Check record identifier, a column of Conditions >>> ("Good", "Fair", "Poor", etc.), a column for the record type and a column >>> for when the record was last updated. What would be _really_ nice is if >>> the Summary column also contained the identifiers for the related objects, >>> so it would look something like this: >>> >>> ID Number Summary Record Type Updated At >>> CC.PP.1880 1971.1.1, None condition check >>> 2015-11-19T03:28:52.337Z >>> >>> Note the addition of "1971.1.1" in the summary column. (FYI, in this >>> example "CC.PP.1880" identifies a particular row in a table of migrated >>> PastPerfect data.) >>> >>> Is this possible? >>> >>> >>> 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 > >

Another thought that Patrick Schmitz had when I chatted with him earlier: If this kind of view is a requirement for SDMoM, it might be sufficient to write a report that they can run. The SQL query might be easier to write than the code required to modify the search results, and we have lots of examples. Reports are sometimes a good fallback for missing CSpace features. Ray On Tue, Nov 24, 2015 at 11:36 AM, Aron Roberts <aron@socrates.berkeley.edu> wrote: > Thanks, Ray - really appreciate your picking up on these aspects of > Peter's task! > > Peter, the code that Ray referred to is here: > > > https://github.com/collectionspace/services/tree/master/3rdparty/nuxeo/nuxeo-platform-listener/updateobjectlocationonmove > > It maintains a (denormalized) value in the Cataloging record that tracks > the object's current location, based on its related > Location/Movement/Inventory records over time. You might be able to > appropriate much of that code for maintaining information on the object > within a condition check; the pattern might be pretty similar. > > On Tue, Nov 24, 2015 at 7:58 AM, Peter Murray <pmurray@chillco.com> wrote: > >> Thanks, Ray -- I hadn't thought of using the computed field >> functionality; patching into the Nuxeo event handler is an interesting >> idea. Definitely non-trivial, but would be a useful path to follow. I had >> a feeling that it wasn't functionality that could be done out-of-the-box. >> >> >> Peter >> >> On Nov 23, 2015, at 6:22 PM, Ray Lee <rhlee@berkeley.edu> wrote: >> >> Hi Peter, >> You've got two problems there. The first is that CSpace doesn't let you >> have more than one field appear in the summary column. The strategy I've >> used to work around that is to create a field that is computed from the >> values of other fields, and configure that computed field to be the >> summary. The other problem is that for a given condition check record, its >> related collectionobjects aren't stored in a field on the condition check; >> there are separate relation records that contain this information. You >> would have to denormalize that data somehow, so that it's available on the >> condition check. The way I would do it is to write a Nuxeo event handler >> that listens for creates, updates, and deletes of relation records, and if >> the relation is between a condition check and a collectionobject, updates a >> field on the condition check. An example of something similar would be the >> code that sets the computed current location on collectionobjects. So this >> is a non-trivial amount of work. >> >> Ray >> >> >> On Mon, Nov 23, 2015 at 12:06 PM, Aron Roberts < >> aron@socrates.berkeley.edu> wrote: >> >>> For starters, it might be worth looking at Ray's notes here, on changing >>> which field appears in the Summary column in search results: >>> >>> https://issues.collectionspace.org/browse/UCJEPS-106 >>> >>> This particular case involved a field in an extension schema, so it's >>> useful as an illustration of how to specify the field's schema, as well. >>> >>> Usual disclaimers apply: this work dates back to 2012, and I don't know >>> for certain whether it reflects current configuration practices. But >>> hopefully this might get you started ... >>> >>> >>> On Mon, Nov 23, 2015 at 10:55 AM, Peter Murray <pmurray@chillco.com> >>> wrote: >>> >>>> SDMoM has a question about the data that appears on the search results >>>> screen and whether it can include the identifier(s) for related record(s). >>>> For instance, what appears in the "Summary" column for Condition Check >>>> records by default is the Condition vocabulary term, so what you get is a >>>> column with the Condition Check record identifier, a column of Conditions >>>> ("Good", "Fair", "Poor", etc.), a column for the record type and a column >>>> for when the record was last updated. What would be _really_ nice is if >>>> the Summary column also contained the identifiers for the related objects, >>>> so it would look something like this: >>>> >>>> ID Number Summary Record Type Updated At >>>> CC.PP.1880 1971.1.1, None condition check >>>> 2015-11-19T03:28:52.337Z >>>> >>>> Note the addition of "1971.1.1" in the summary column. (FYI, in this >>>> example "CC.PP.1880" identifies a particular row in a table of migrated >>>> PastPerfect data.) >>>> >>>> Is this possible? >>>> >>>> >>>> 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 >> >> > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

Aron: core code additions/modifications are out of scope for the moment -- we'll have to see kinds of things bump up in priority in a next phase. I appreciate the pointer to the example. The code itself doesn't look too bad. I didn't expect the use of OSGi to hook into Nuxeo; I had envisioned a message bus listener. Ray: a report might be a good fall-back. We'll have to see what that looks like. Thanks Aron and Ray, Peter > On Nov 24, 2015, at 4:06 PM, Ray Lee <rhlee@berkeley.edu> wrote: > > Another thought that Patrick Schmitz had when I chatted with him earlier: If this kind of view is a requirement for SDMoM, it might be sufficient to write a report that they can run. The SQL query might be easier to write than the code required to modify the search results, and we have lots of examples. Reports are sometimes a good fallback for missing CSpace features. > > Ray > > On Tue, Nov 24, 2015 at 11:36 AM, Aron Roberts <aron@socrates.berkeley.edu <mailto:aron@socrates.berkeley.edu>> wrote: > Thanks, Ray - really appreciate your picking up on these aspects of Peter's task! > > Peter, the code that Ray referred to is here: > > https://github.com/collectionspace/services/tree/master/3rdparty/nuxeo/nuxeo-platform-listener/updateobjectlocationonmove <https://github.com/collectionspace/services/tree/master/3rdparty/nuxeo/nuxeo-platform-listener/updateobjectlocationonmove> > > It maintains a (denormalized) value in the Cataloging record that tracks the object's current location, based on its related Location/Movement/Inventory records over time. You might be able to appropriate much of that code for maintaining information on the object within a condition check; the pattern might be pretty similar. > > On Tue, Nov 24, 2015 at 7:58 AM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: > Thanks, Ray -- I hadn't thought of using the computed field functionality; patching into the Nuxeo event handler is an interesting idea. Definitely non-trivial, but would be a useful path to follow. I had a feeling that it wasn't functionality that could be done out-of-the-box. > > > Peter > >> On Nov 23, 2015, at 6:22 PM, Ray Lee <rhlee@berkeley.edu <mailto:rhlee@berkeley.edu>> wrote: >> >> Hi Peter, >> You've got two problems there. The first is that CSpace doesn't let you have more than one field appear in the summary column. The strategy I've used to work around that is to create a field that is computed from the values of other fields, and configure that computed field to be the summary. The other problem is that for a given condition check record, its related collectionobjects aren't stored in a field on the condition check; there are separate relation records that contain this information. You would have to denormalize that data somehow, so that it's available on the condition check. The way I would do it is to write a Nuxeo event handler that listens for creates, updates, and deletes of relation records, and if the relation is between a condition check and a collectionobject, updates a field on the condition check. An example of something similar would be the code that sets the computed current location on collectionobjects. So this is a non-trivial amount of work. >> >> Ray >> >> >> On Mon, Nov 23, 2015 at 12:06 PM, Aron Roberts <aron@socrates.berkeley.edu <mailto:aron@socrates.berkeley.edu>> wrote: >> For starters, it might be worth looking at Ray's notes here, on changing which field appears in the Summary column in search results: >> >> https://issues.collectionspace.org/browse/UCJEPS-106 <https://issues.collectionspace.org/browse/UCJEPS-106> >> >> This particular case involved a field in an extension schema, so it's useful as an illustration of how to specify the field's schema, as well. >> >> Usual disclaimers apply: this work dates back to 2012, and I don't know for certain whether it reflects current configuration practices. But hopefully this might get you started ... >> >> >> On Mon, Nov 23, 2015 at 10:55 AM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >> SDMoM has a question about the data that appears on the search results screen and whether it can include the identifier(s) for related record(s). For instance, what appears in the "Summary" column for Condition Check records by default is the Condition vocabulary term, so what you get is a column with the Condition Check record identifier, a column of Conditions ("Good", "Fair", "Poor", etc.), a column for the record type and a column for when the record was last updated. What would be _really_ nice is if the Summary column also contained the identifiers for the related objects, so it would look something like this: >> >> ID Number Summary Record Type Updated At >> CC.PP.1880 1971.1.1, None condition check 2015-11-19T03:28:52.337Z >> >> Note the addition of "1971.1.1" in the summary column. (FYI, in this example "CC.PP.1880" identifies a particular row in a table of migrated PastPerfect data.) >> >> Is this possible? >> >> >> Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company