Hi Chris, if you're coming from v3.0 to 4.0 there might be some data changes. We'll try to remind ourselves what changed when, though it should also be in the release notes. I've harvested some of that below: http://wiki.collectionspace.org/display/collectionspace/Release+3.2 > CollectionSpace version 3.2 now requires PostgreSQL 9.1 or higher. > > http://wiki.collectionspace.org/display/collectionspace/Release+3.2.1 > New 'formatted display name' field in authority terms (CSPACE-5818) > > A termFormattedDisplayName field has been added - to date, in the Services layer only - to the repeatable term information group of every authority term record. > > This optional field can be used for storage of formatted display names using a museum's choice of markup/styling (expected to typically be HTML markup). For instance, one museum plans to style parts of scientific taxonomy terms in italics using this field. > > Note that, while this addition means you can now store data in this field via data import or REST API calls, to use it fully from within CollectionSpace's user interface, you'll also need to add this field to the relevant Application layer configuration file(s) and UI layer HTML template file(s). > > Ray Lee provided the following additional information about how to make use of HTML markup stored in this field: > > In iReports, you have to configure the field specially to be rendered as formatted text: > http://jasperreports.sourceforge.net/sample.reference/markup/index.html > For use in external webapps, HTML templating languages generally have some way of specifying that a string contains HTML that should be rendered. > In JavaScript applications, you'd set innerHTML instead of innerText/textContent. This was needed for scientific names but might be helpful in some cases. I think you can also just ignore it. http://wiki.collectionspace.org/display/collectionspace/Release+4.0 > Notes service has been deactivated (CSPACE-6189) > > A "Notes" service has long been present in CollectionSpace, but was never exposed in the system's user interface, nor has it been used by other services, as was originally contemplated (see Annotation Service Notes). This service has been deactivated and is now deprecated. > > I'll let others remind us if anything else happened. I know that at some point all records needed a refname in collectionspace_core. We developed some SQL to help with things like that. Thanks, Chris On Nov 20, 2013, at 1:53 AM, Christopher Pott wrote: > Thank you Jesse, and others, who responded to my concerns about upgrading. There’s some great information here to get us started. From what I read I get the impression that the upgrade does not result in structural changes to the nuxeo or cspace databases and that it’s ‘merely’ a question of code merging and deploying over the existing implementation (ie, no new tables need generating or data migrated). Have I understood correctly? > > Regards, > Chris > > Fra: Jesse Martinez [mailto:mjesse@gmail.com] > Sendt: 18. november 2013 18:44 > Til: Aron Roberts > Cc: Christopher Pott; talk@lists.collectionspace.org > Emne: Re: [Talk] CSpace procedures for Exhibitions and Condition Check/Conservation? > > Some recent work of mine for the Walker involved upgrading from v3.3 to v4.0. Overall, this work took roughly a week and included making sure existing schema extensions matched new app layer syntax (make sure tags and attributes match/exist) and porting over new procedures. Porting over the new procedures consumed the bulk of the week-long time as this involved a small learning curve as how the app layer controls the configuration. And a good amount of testing. > > Ray shared to the list his workflow on upgrading a UCB client to v4.0 and I recommend looking at his work. I believe it involved merging v4 onto his branch and working out the differences/conflicts. I based my upgrade workflow on Ray's but instead of merging code bases I started from a fresh v4 branch and added my code changes piecemeal. It was a lot slower but I was able to see piece-by-piece how things had changed. > > Previous discussion w/Ray's workflow: > http://lists.collectionspace.org/pipermail/talk_lists.collectionspace.org/2013-October/001595.html > > - Jesse > > > On Mon, Nov 18, 2013 at 12:26 PM, Aron Roberts <aronroberts@gmail.com> wrote: > > BTW I was concerned to read that it takes two weeks work to upgrade one procedure to version 4.0 as our entire system is currently back at 3.0 (with a large number of extensions), and we’d like to upgrade to 4.0 within the next half year. Has anyone attempted a similar update on a live system? > > I suspect that was a very conservative estimate, and that we might be > able to get a new procedure integrated in some fraction of that time. > The hardest part - and this could literally take the bulk of that time > - is getting the schema (and any expectations around workflow or other > subtleties) worked out, especially if there are multiple, disparate > community contributions. The actual coding and testing isn't *that* > time consuming. > > On Mon, Nov 18, 2013 at 5:47 AM, Christopher Pott > <Christopher.Pott@smk.dk> wrote: > > Hi Chris, > > > > > > > > The team at SMK is planning on significantly extending our Exhibition > > Procedure (to replace our current exhibition management system) and this may > > fit with some of the requirements from Oakland. As a Procedure in itself > > rather than an Authority this is a different approach to Jesse’s which you > > may also want to consider as a candidate for merging. We’ve already planned > > to make some resources available for this work and we’d be able to extend > > this to include code contributions/merging. In any case, we’ll be working on > > this in the same timeframe so it would make sense to get together and > > discuss the requirements/possibilities around this area. > > > > > > > > As far as conservation data is concerned, we’ll be focusing on how we will > > link/integrate CollectionSpace collections data with Conservationspace > > (under development), but this will likely fall outside of the 2014 > > February-June timeframe. > > > > > > > > BTW I was concerned to read that it takes two weeks work to upgrade one > > procedure to version 4.0 as our entire system is currently back at 3.0 (with > > a large number of extensions), and we’d like to upgrade to 4.0 within the > > next half year. Has anyone attempted a similar update on a live system? > > > > > > > > Regards, > > > > Chris > > > > > > > > IT Developer > > > > Statens Museum for Kunst > > > > ________________________________ > > > > Fra: Talk [mailto:talk-bounces@lists.collectionspace.org] På vegne af Chris > > Hoffman > > Sendt: 14. november 2013 18:51 > > Til: talk@lists.collectionspace.org List > > Emne: [Talk] CSpace procedures for Exhibitions and Condition > > Check/Conservation? > > > > > > > > Hello CollectionSpace community, > > > > > > > > I talked with Al Bersch yesterday about his exciting announcement that > > Oakland Museum of California (OMCA) will be using CollectionSpace. We > > talked mainly about the web applications that UC Berkeley has been building > > on top of CollectionSpace, but we also discussed a couple customizations > > they would probably want to include. They need procedures for Exhibition > > tracking and Condition Checking/Conservation/Treatments. We at Berkeley are > > also eager to make these procedures available to our museums. > > > > > > > > Back in July, Jesse Martinez submitted a contribution for Condition > > Checking. You might think that is then ready to go. However, to update it > > to version 4.0 of CollectionSpace will take a couple of weeks of work. > > > > > > > > For Exhibitions, we know that SMK has developed a basic procedure with a few > > fields but that they are hoping CollectionSpace will have something more > > comprehensive. Jesse or others: Are you working on something already along > > these lines? > > > > > > > > I told Al I think there is an opportunity for several deployers to work > > together to get some of these procedures into the core of CollectionSpace > > where they belong. Would anyone be interested in working with Berkeley and > > OMCA in the February through June time frame? > > > > > > > > Regards, > > > > Chris > > > > > > > > Chris Hoffman, Ph.D. > > > > Manager of Informatics Services > > > > IST-Research Information Technologies, UC Berkeley > > > > chris.hoffman@berkeley.edu > > > > 510-642-9643 > > > > > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Thanks Chris, these are just the kind of issues we were concerned about - but there doesn't seem to be anything too painful here (we have the refname changes already). We will probably attempt an upgrade early 2014. /Chris ________________________________ Fra: Chris Hoffman [mailto:chris_h@berkeley.edu] Sendt: 20. november 2013 18:51 Til: Christopher Pott Cc: 'Jesse Martinez'; 'talk@lists.collectionspace.org' Emne: Re: [Talk] CSpace procedures for Exhibitions and Condition Check/Conservation? Hi Chris, if you're coming from v3.0 to 4.0 there might be some data changes. We'll try to remind ourselves what changed when, though it should also be in the release notes. I've harvested some of that below: http://wiki.collectionspace.org/display/collectionspace/Release+3.2 CollectionSpace version 3.2 now requires PostgreSQL 9.1 or higher. http://wiki.collectionspace.org/display/collectionspace/Release+3.2.1 New 'formatted display name' field in authority terms (CSPACE-5818<http://issues.collectionspace.org/browse/CSPACE-5818>) A termFormattedDisplayName field has been added - to date, in the Services layer only - to the repeatable term information group of every authority term record. This optional field can be used for storage of formatted display names using a museum's choice of markup/styling (expected to typically be HTML markup). For instance, one museum plans to style parts of scientific taxonomy terms in italics using this field. Note that, while this addition means you can now store data in this field via data import or REST API calls, to use it fully from within CollectionSpace's user interface, you'll also need to add this field to the relevant Application layer configuration file(s) and UI layer HTML template file(s). Ray Lee provided the following additional information about how to make use of HTML markup stored in this field: * In iReports, you have to configure the field specially to be rendered as formatted text: http://jasperreports.sourceforge.net/sample.reference/markup/index.html * For use in external webapps, HTML templating languages generally have some way of specifying that a string contains HTML that should be rendered. * In JavaScript applications, you'd set innerHTML instead of innerText/textContent. This was needed for scientific names but might be helpful in some cases. I think you can also just ignore it. http://wiki.collectionspace.org/display/collectionspace/Release+4.0 Notes service has been deactivated (CSPACE-6189<http://issues.collectionspace.org/browse/CSPACE-6189>) A "Notes" service has long been present in CollectionSpace, but was never exposed in the system's user interface, nor has it been used by other services, as was originally contemplated (see Annotation Service Notes<http://wiki.collectionspace.org/display/collectionspace/Annotation+Service+Notes>). This service has been deactivated and is now deprecated. I'll let others remind us if anything else happened. I know that at some point all records needed a refname in collectionspace_core. We developed some SQL to help with things like that. Thanks, Chris On Nov 20, 2013, at 1:53 AM, Christopher Pott wrote: Thank you Jesse, and others, who responded to my concerns about upgrading. There's some great information here to get us started. From what I read I get the impression that the upgrade does not result in structural changes to the nuxeo or cspace databases and that it's 'merely' a question of code merging and deploying over the existing implementation (ie, no new tables need generating or data migrated). Have I understood correctly? Regards, Chris ________________________________ Fra: Jesse Martinez [mailto:mjesse@gmail.com] Sendt: 18. november 2013 18:44 Til: Aron Roberts Cc: Christopher Pott; talk@lists.collectionspace.org<mailto:talk@lists.collectionspace.org> Emne: Re: [Talk] CSpace procedures for Exhibitions and Condition Check/Conservation? Some recent work of mine for the Walker involved upgrading from v3.3 to v4.0. Overall, this work took roughly a week and included making sure existing schema extensions matched new app layer syntax (make sure tags and attributes match/exist) and porting over new procedures. Porting over the new procedures consumed the bulk of the week-long time as this involved a small learning curve as how the app layer controls the configuration. And a good amount of testing. Ray shared to the list his workflow on upgrading a UCB client to v4.0 and I recommend looking at his work. I believe it involved merging v4 onto his branch and working out the differences/conflicts. I based my upgrade workflow on Ray's but instead of merging code bases I started from a fresh v4 branch and added my code changes piecemeal. It was a lot slower but I was able to see piece-by-piece how things had changed. Previous discussion w/Ray's workflow: http://lists.collectionspace.org/pipermail/talk_lists.collectionspace.org/2013-October/001595.html - Jesse On Mon, Nov 18, 2013 at 12:26 PM, Aron Roberts <aronroberts@gmail.com<mailto:aronroberts@gmail.com>> wrote: > BTW I was concerned to read that it takes two weeks work to upgrade one procedure to version 4.0 as our entire system is currently back at 3.0 (with a large number of extensions), and we'd like to upgrade to 4.0 within the next half year. Has anyone attempted a similar update on a live system? I suspect that was a very conservative estimate, and that we might be able to get a new procedure integrated in some fraction of that time. The hardest part - and this could literally take the bulk of that time - is getting the schema (and any expectations around workflow or other subtleties) worked out, especially if there are multiple, disparate community contributions. The actual coding and testing isn't *that* time consuming. On Mon, Nov 18, 2013 at 5:47 AM, Christopher Pott <Christopher.Pott@smk.dk<mailto:Christopher.Pott@smk.dk>> wrote: > Hi Chris, > > > > The team at SMK is planning on significantly extending our Exhibition > Procedure (to replace our current exhibition management system) and this may > fit with some of the requirements from Oakland. As a Procedure in itself > rather than an Authority this is a different approach to Jesse's which you > may also want to consider as a candidate for merging. We've already planned > to make some resources available for this work and we'd be able to extend > this to include code contributions/merging. In any case, we'll be working on > this in the same timeframe so it would make sense to get together and > discuss the requirements/possibilities around this area. > > > > As far as conservation data is concerned, we'll be focusing on how we will > link/integrate CollectionSpace collections data with Conservationspace > (under development), but this will likely fall outside of the 2014 > February-June timeframe. > > > > BTW I was concerned to read that it takes two weeks work to upgrade one > procedure to version 4.0 as our entire system is currently back at 3.0 (with > a large number of extensions), and we'd like to upgrade to 4.0 within the > next half year. Has anyone attempted a similar update on a live system? > > > > Regards, > > Chris > > > > IT Developer > > Statens Museum for Kunst > > ________________________________ > > Fra: Talk [mailto:talk-bounces@lists.collectionspace.org<mailto:talk-bounces@lists.collectionspace.org>] På vegne af Chris > Hoffman > Sendt: 14. november 2013 18:51 > Til: talk@lists.collectionspace.org<mailto:talk@lists.collectionspace.org> List > Emne: [Talk] CSpace procedures for Exhibitions and Condition > Check/Conservation? > > > > Hello CollectionSpace community, > > > > I talked with Al Bersch yesterday about his exciting announcement that > Oakland Museum of California (OMCA) will be using CollectionSpace. We > talked mainly about the web applications that UC Berkeley has been building > on top of CollectionSpace, but we also discussed a couple customizations > they would probably want to include. They need procedures for Exhibition > tracking and Condition Checking/Conservation/Treatments. We at Berkeley are > also eager to make these procedures available to our museums. > > > > Back in July, Jesse Martinez submitted a contribution for Condition > Checking. You might think that is then ready to go. However, to update it > to version 4.0 of CollectionSpace will take a couple of weeks of work. > > > > For Exhibitions, we know that SMK has developed a basic procedure with a few > fields but that they are hoping CollectionSpace will have something more > comprehensive. Jesse or others: Are you working on something already along > these lines? > > > > I told Al I think there is an opportunity for several deployers to work > together to get some of these procedures into the core of CollectionSpace > where they belong. Would anyone be interested in working with Berkeley and > OMCA in the February through June time frame? > > > > Regards, > > Chris > > > > Chris Hoffman, Ph.D. > > Manager of Informatics Services > > IST-Research Information Technologies, UC Berkeley > > chris.hoffman@berkeley.edu<mailto:chris.hoffman@berkeley.edu> > > 510-642-9643<tel:510-642-9643> > > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org<mailto:Talk@lists.collectionspace.org> > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > _______________________________________________ Talk mailing list Talk@lists.collectionspace.org<mailto:Talk@lists.collectionspace.org> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org _______________________________________________ Talk mailing list Talk@lists.collectionspace.org<mailto:Talk@lists.collectionspace.org> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org