Susan, If the schema you're using has any extension, then you'll need to append the subjectDocumentType/objectDocumentType string w/ "Tenent__" e.g. when Ray fixed the PAHMA extension on dev 1.12, the "Movement" becomes "MovementTenant15" (and when I forgot to change my xxxDocumentType in the "relation" import XML file, none of the relations showed up). Looking at all the relations in current dev pahma 1.12, it looks like for "movement to object" relation, using the "subjectCsid" together w/ "subjectDocumentType" is enough (i.e. w/o "subjectUri"), but the "object to movement" relations all seem to have all three parts. I'm playing it safe so I always have all three of them. I also don't know if documentTYpe1/documentType2 are needed if subjectDocumentType/ objectDocumentType are there. Certainly better documentation on the "relation" schema is needed. Yuteh > From cspace-ucb-deployments-bounces+yuteh=hobbes.berkeley.edu@lists.berkeley.edu Thu Jan 5 18:58:55 2012 > From: Susan Stone <sstone@socrates.berkeley.edu> > To: Patrick Schmitz <pschmitz@berkeley.edu> > Subject: Re: services-tenant-singular > > I've also become very confused about what I need to put as > subjectDocumentType etc. in relation records I import, since it appears > to have changed in 1.19 (it used to have to be all lower case). I have > noticed things like CollectionObjectTenant42 for subjectDocumentType on > relation records that I created through the UI in 1.19 and then > exported, but I don't know if I need to use that myself--I hope not. The > app seems to use the new subjectUri/objectUri for some things it used to > need the subjectDocumentType/objectDocumentType for. > > I also have had problems with records not showing up in the UI in > movement records (there might have been a JIRA for this) and an app > message "error fetching related term" when I try to leave a storage > location with broader term relations. In general, I had a bunch of > problems with relations in 1.19, whether bugs or changes that weren't > documented, but I lost track of them over the holidays. > > Susan > > > I am not sure On 01/05/2012 05:11 PM, Patrick Schmitz wrote: > > Thanks Ray. On my list of things I have talked to ChrisM about refactoring > > is the name of this element to be "services-document-type" which would help > > a little. Initially, it was something of a mystery to them but we talked > > about it in November, and now they understand what it is and why it is not > > just singular, but has real semantics (as the DocType). > > > > Patrick > > > >> -----Original Message----- > >> From: cspace-ucb-deployments-bounces@lists.berkeley.edu > >> [mailto:cspace-ucb-deployments-bounces@lists.berkeley.edu] On > >> Behalf Of Ray Lee > >> Sent: Thursday, January 05, 2012 4:59 PM > >> To: cspace-ucb-deployments@lists.berkeley.edu > >> Cc: talk@lists.collectionspace.org > >> Subject: services-tenant-singular > >> > >> Hi Deployers, > >> I wanted to give a heads up about an important app layer > >> configuration setting that I've been missing, and that you > >> may be too. I haven't found any documentation about this, and > >> the setting is not properly configured in the lifesci tenant, > >> which is broken because of it. This affects those of you who > >> are doing schema extensions in CollectionSpace v1.12 and above. > >> > >> If your tenant has schema extensions for a record type (let's > >> say CollectionObject), you need to edit the base-<record > >> type>.xml file (e.g. base-collectionobject.xml). In it, you > >> need to change the content of the services-tenant-singular > >> element. Basically, you need to take whatever value is there, > >> and append Tenant<your tenant number> to the end. So if my > >> tenant number is 15, the value in base-collectionobject.xml would be: > >> > >> <services-tenant-singular>CollectionObjectTenant15</services-t > > enant-singular> > >> > >> What you're really doing is putting the Nuxeo doctype name > >> for the record type, for your tenant. If you configured the > >> services layer correctly, it's going to be<the default > >> doctype name>Tenant<tenant number>. > >> > >> If you haven't done this, you may see the following symptom: > >> If you add a record with a schema extension as a related > >> record to something else, it will fail to appear in the > >> related records list on the right side of the page. This is > >> because the app layer finds the related records for a given > >> record by making a series of queries to the services layer, > >> of the form > >> > >> relations?sbj=beef5632-0a52-4178-931d&objType=Loanout > >> relations?sbj=beef5632-0a52-4178-931d&objType=Acquisition > >> relations?sbj=beef5632-0a52-4178-931d&objType=CollectionObject > >> ... > >> > >> The objType values are those specified in > >> services-tenant-singular. If you've extended CollectionObject > >> for the tenant whose id is 15, objType=CollectionObject won't > >> locate any related records, because the relations service > >> knows of that object as CollectionObjectTenant15. > >> > >> Changing the services-tenant-singular value in the > >> appropriate xml files has solved a bunch of problems for me, > >> except for some bugs with extended Location records. I'm > >> unsure what to do about Location records with schema > >> extensions, since the app layer config for Location is > >> different than the others. In base-authority-location.xml, > >> services-tenant-singular is set to Locationauthority, not the > >> expected Locationitem. Why? > >> > >> Ray > >> > >> > >> > >> > > > > > >

One thing I've noticed recently is that a relationship created with a newly created record -- via the + add record button dialog -- creates the new record but doesn't properly show it as a related record. It appears only pre-existing records can have a relationship created. I tested this with a locally extended collectionobject schema with v2.0. - Jesse On Fri, Jan 6, 2012 at 8:44 PM, Yuteh Theresa Cheng <yuteh@hobbes.berkeley.edu> wrote: > Susan, > > If the schema you're using has any extension, then you'll need to append the > subjectDocumentType/objectDocumentType string w/ "Tenent__" e.g. when Ray fixed > the PAHMA extension on dev 1.12, the "Movement" becomes "MovementTenant15" > (and when I forgot to change my xxxDocumentType in the "relation" import XML > file, none of the relations showed up). > > Looking at all the relations in current dev pahma 1.12, it looks like for > "movement to object" relation, using the "subjectCsid" together w/ > "subjectDocumentType" is enough (i.e. w/o "subjectUri"), but the > "object to movement" relations all seem to have all three parts. > I'm playing it safe so I always have all three of them.  I also don't > know if documentTYpe1/documentType2 are needed if subjectDocumentType/ > objectDocumentType are there.  Certainly better documentation on > the "relation" schema is needed. > > Yuteh > >> From cspace-ucb-deployments-bounces+yuteh=hobbes.berkeley.edu@lists.berkeley.edu  Thu Jan  5 18:58:55 2012 >> From: Susan Stone <sstone@socrates.berkeley.edu> >> To: Patrick Schmitz <pschmitz@berkeley.edu> >> Subject: Re: services-tenant-singular >> >> I've also become very confused about what I need to put as >> subjectDocumentType etc. in relation records I import, since it appears >> to have changed in 1.19 (it used to have to be all lower case). I have >> noticed things like CollectionObjectTenant42 for subjectDocumentType on >> relation records that I created through the UI in 1.19 and then >> exported, but I don't know if I need to use that myself--I hope not. The >> app seems to use the new subjectUri/objectUri for some things it used to >> need the subjectDocumentType/objectDocumentType for. >> >> I also have had problems with records not showing up in the UI in >> movement records (there might have been a JIRA for this) and an app >> message "error fetching related term" when I try to leave a storage >> location with broader term relations. In general, I had a bunch of >> problems with relations in 1.19, whether bugs or changes that weren't >> documented, but I lost track of them over the holidays. >> >> Susan >> >> >> I am not sure On 01/05/2012 05:11 PM, Patrick Schmitz wrote: >> > Thanks Ray. On my list of things I have talked to ChrisM about refactoring >> > is the name of this element to be "services-document-type" which would help >> > a little. Initially, it was something of a mystery to them but we talked >> > about it in November, and now they understand what it is and why it is not >> > just singular, but has real semantics (as the DocType). >> > >> > Patrick >> > >> >> -----Original Message----- >> >> From: cspace-ucb-deployments-bounces@lists.berkeley.edu >> >> [mailto:cspace-ucb-deployments-bounces@lists.berkeley.edu] On >> >> Behalf Of Ray Lee >> >> Sent: Thursday, January 05, 2012 4:59 PM >> >> To: cspace-ucb-deployments@lists.berkeley.edu >> >> Cc: talk@lists.collectionspace.org >> >> Subject: services-tenant-singular >> >> >> >> Hi Deployers, >> >> I wanted to give a heads up about an important app layer >> >> configuration setting that I've been missing, and that you >> >> may be too. I haven't found any documentation about this, and >> >> the setting is not properly configured in the lifesci tenant, >> >> which is broken because of it. This affects those of you who >> >> are doing schema extensions in CollectionSpace v1.12 and above. >> >> >> >> If your tenant has schema extensions for a record type (let's >> >> say CollectionObject), you need to edit the base-<record >> >> type>.xml file (e.g. base-collectionobject.xml). In it, you >> >> need to change the content of the services-tenant-singular >> >> element. Basically, you need to take whatever value is there, >> >> and append Tenant<your tenant number>  to the end. So if my >> >> tenant number is 15, the value in base-collectionobject.xml would be: >> >> >> >> <services-tenant-singular>CollectionObjectTenant15</services-t >> > enant-singular> >> >> >> >> What you're really doing is putting the Nuxeo doctype name >> >> for the record type, for your tenant. If you configured the >> >> services layer correctly, it's going to be<the default >> >> doctype name>Tenant<tenant number>. >> >> >> >> If you haven't done this, you may see the following symptom: >> >> If you add a record with a schema extension as a related >> >> record to something else, it will fail to appear in the >> >> related records list on the right side of the page. This is >> >> because the app layer finds the related records for a given >> >> record by making a series of queries to the services layer, >> >> of the form >> >> >> >> relations?sbj=beef5632-0a52-4178-931d&objType=Loanout >> >> relations?sbj=beef5632-0a52-4178-931d&objType=Acquisition >> >> relations?sbj=beef5632-0a52-4178-931d&objType=CollectionObject >> >> ... >> >> >> >> The objType values are those specified in >> >> services-tenant-singular. If you've extended CollectionObject >> >> for the tenant whose id is 15, objType=CollectionObject won't >> >> locate any related records, because the relations service >> >> knows of that object as CollectionObjectTenant15. >> >> >> >> Changing the services-tenant-singular value in the >> >> appropriate xml files has solved a bunch of problems for me, >> >> except for some bugs with extended Location records. I'm >> >> unsure what to do about Location records with schema >> >> extensions, since the app layer config for Location is >> >> different than the others. In base-authority-location.xml, >> >> services-tenant-singular is set to Locationauthority, not the >> >> expected Locationitem. Why? >> >> >> >> Ray >> >> >> >> >> >> >> >> >> > >> > >> >> > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Have you filed a JIRA for this? Sounds kinda funky to me... > -----Original Message----- > From: cspace-ucb-deployments-bounces@lists.berkeley.edu > [mailto:cspace-ucb-deployments-bounces@lists.berkeley.edu] On > Behalf Of Jesse Martinez > Sent: Thursday, January 12, 2012 12:47 PM > To: Yuteh Theresa Cheng > Cc: cspace-ucb-deployments@lists.berkeley.edu; > talk@lists.collectionspace.org > Subject: Re: cspacedeploy [Talk] services-tenant-singular > > One thing I've noticed recently is that a relationship > created with a newly created record -- via the + add record > button dialog -- creates the new record but doesn't properly > show it as a related record. It appears only pre-existing > records can have a relationship created. > > I tested this with a locally extended collectionobject schema > with v2.0. > > - Jesse > > On Fri, Jan 6, 2012 at 8:44 PM, Yuteh Theresa Cheng > <yuteh@hobbes.berkeley.edu> wrote: > > Susan, > > > > If the schema you're using has any extension, then you'll need to > > append the subjectDocumentType/objectDocumentType string w/ > "Tenent__" > > e.g. when Ray fixed the PAHMA extension on dev 1.12, the > "Movement" becomes "MovementTenant15" > > (and when I forgot to change my xxxDocumentType in the "relation" > > import XML file, none of the relations showed up). > > > > Looking at all the relations in current dev pahma 1.12, it > looks like > > for "movement to object" relation, using the "subjectCsid" > together w/ > > "subjectDocumentType" is enough (i.e. w/o "subjectUri"), but the > > "object to movement" relations all seem to have all three parts. > > I'm playing it safe so I always have all three of them.  I > also don't > > know if documentTYpe1/documentType2 are needed if > subjectDocumentType/ > > objectDocumentType are there.  Certainly better > documentation on the > > "relation" schema is needed. > > > > Yuteh > > > >> From > >> > cspace-ucb-deployments-bounces+yuteh=hobbes.berkeley.edu@lists.berkel > >> ey.edu  Thu Jan  5 18:58:55 2012 > >> From: Susan Stone <sstone@socrates.berkeley.edu> > >> To: Patrick Schmitz <pschmitz@berkeley.edu> > >> Subject: Re: services-tenant-singular > >> > >> I've also become very confused about what I need to put as > >> subjectDocumentType etc. in relation records I import, since it > >> appears to have changed in 1.19 (it used to have to be all lower > >> case). I have noticed things like CollectionObjectTenant42 for > >> subjectDocumentType on relation records that I created > through the UI > >> in 1.19 and then exported, but I don't know if I need to use that > >> myself--I hope not. The app seems to use the new > subjectUri/objectUri > >> for some things it used to need the > subjectDocumentType/objectDocumentType for. > >> > >> I also have had problems with records not showing up in the UI in > >> movement records (there might have been a JIRA for this) > and an app > >> message "error fetching related term" when I try to leave > a storage > >> location with broader term relations. In general, I had a bunch of > >> problems with relations in 1.19, whether bugs or changes > that weren't > >> documented, but I lost track of them over the holidays. > >> > >> Susan > >> > >> > >> I am not sure On 01/05/2012 05:11 PM, Patrick Schmitz wrote: > >> > Thanks Ray. On my list of things I have talked to ChrisM about > >> > refactoring is the name of this element to be > >> > "services-document-type" which would help a little. > Initially, it > >> > was something of a mystery to them but we talked about it in > >> > November, and now they understand what it is and why it > is not just singular, but has real semantics (as the DocType). > >> > > >> > Patrick > >> > > >> >> -----Original Message----- > >> >> From: cspace-ucb-deployments-bounces@lists.berkeley.edu > >> >> [mailto:cspace-ucb-deployments-bounces@lists.berkeley.edu] On > >> >> Behalf Of Ray Lee > >> >> Sent: Thursday, January 05, 2012 4:59 PM > >> >> To: cspace-ucb-deployments@lists.berkeley.edu > >> >> Cc: talk@lists.collectionspace.org > >> >> Subject: services-tenant-singular > >> >> > >> >> Hi Deployers, > >> >> I wanted to give a heads up about an important app layer > >> >> configuration setting that I've been missing, and that > you may be > >> >> too. I haven't found any documentation about this, and > the setting > >> >> is not properly configured in the lifesci tenant, which > is broken > >> >> because of it. This affects those of you who are doing schema > >> >> extensions in CollectionSpace v1.12 and above. > >> >> > >> >> If your tenant has schema extensions for a record type > (let's say > >> >> CollectionObject), you need to edit the base-<record > >> >> type>.xml file (e.g. base-collectionobject.xml). In it, you > >> >> need to change the content of the services-tenant-singular > >> >> element. Basically, you need to take whatever value is > there, and > >> >> append Tenant<your tenant number>  to the end. So if my tenant > >> >> number is 15, the value in base-collectionobject.xml would be: > >> >> > >> >> <services-tenant-singular>CollectionObjectTenant15</services-t > >> > enant-singular> > >> >> > >> >> What you're really doing is putting the Nuxeo doctype > name for the > >> >> record type, for your tenant. If you configured the > services layer > >> >> correctly, it's going to be<the default doctype > name>Tenant<tenant > >> >> number>. > >> >> > >> >> If you haven't done this, you may see the following symptom: > >> >> If you add a record with a schema extension as a > related record to > >> >> something else, it will fail to appear in the related > records list > >> >> on the right side of the page. This is because the app > layer finds > >> >> the related records for a given record by making a series of > >> >> queries to the services layer, of the form > >> >> > >> >> relations?sbj=beef5632-0a52-4178-931d&objType=Loanout > >> >> relations?sbj=beef5632-0a52-4178-931d&objType=Acquisition > >> >> relations?sbj=beef5632-0a52-4178-931d&objType=CollectionObject > >> >> ... > >> >> > >> >> The objType values are those specified in > >> >> services-tenant-singular. If you've extended > CollectionObject for > >> >> the tenant whose id is 15, objType=CollectionObject > won't locate > >> >> any related records, because the relations service > knows of that > >> >> object as CollectionObjectTenant15. > >> >> > >> >> Changing the services-tenant-singular value in the > appropriate xml > >> >> files has solved a bunch of problems for me, except for > some bugs > >> >> with extended Location records. I'm unsure what to do about > >> >> Location records with schema extensions, since the app layer > >> >> config for Location is different than the others. In > >> >> base-authority-location.xml, services-tenant-singular is set to > >> >> Locationauthority, not the expected Locationitem. Why? > >> >> > >> >> Ray > >> >> > >> >> > >> >> > >> >> > >> > > >> > > >> > >> > > > > _______________________________________________ > > Talk mailing list > > Talk@lists.collectionspace.org > > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectio > > nspace.org > >