RL
Ray Lee
Fri, Jan 6, 2012 12:59 AM
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-tenant-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
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-tenant-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
PS
Patrick Schmitz
Fri, Jan 6, 2012 1:11 AM
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
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
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
>
>
>
>
SS
Susan Stone
Fri, Jan 6, 2012 2:58 AM
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
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
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
>>
>>
>>
>>
>
>
JM
Jesse Martinez
Fri, Jan 6, 2012 4:58 PM
Thanks Ray,
This has indeed worked for our deployment here at MMI. I currently
have two extended procedural schemas in place: collectionobject and
acquisition, and altering the <services-tenant-singular> element for
both has fixed the issue with related records not appearing in the UI.
On Thu, Jan 5, 2012 at 7:59 PM, Ray Lee rhlee@berkeley.edu wrote:
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-tenant-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
Thanks Ray,
This has indeed worked for our deployment here at MMI. I currently
have two extended procedural schemas in place: collectionobject and
acquisition, and altering the <services-tenant-singular> element for
both has fixed the issue with related records not appearing in the UI.
- Jesse
On Thu, Jan 5, 2012 at 7:59 PM, Ray Lee <rhlee@berkeley.edu> wrote:
> 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-tenant-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
RL
Ray Lee
Mon, Apr 16, 2012 10:58 PM
Hi Everyone,
I have an update to this message. I've been updating one of our deployments to use the latest collectionspace code checked out of git, and I've found that the opposite of what is stated below is now true. For 2.3, it looks like it will no longer be necessary to change services-tenant-singular in the app layer. In fact, for related records to show up properly in the sidebar, you must not change it. This is a good thing, as it simplifies configuration, but you will need to be aware of it when you upgrade to 2.3.
Thanks,
Ray
On Jan 5, 2012, at 4:59 PM, Ray Lee wrote:
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-tenant-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
Hi Everyone,
I have an update to this message. I've been updating one of our deployments to use the latest collectionspace code checked out of git, and I've found that the opposite of what is stated below is now true. For 2.3, it looks like it will no longer be necessary to change services-tenant-singular in the app layer. In fact, for related records to show up properly in the sidebar, you must not change it. This is a good thing, as it simplifies configuration, but you will need to be aware of it when you upgrade to 2.3.
Thanks,
Ray
On Jan 5, 2012, at 4:59 PM, Ray Lee wrote:
> 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-tenant-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
>
>
>
S
sstone@socrates.berkeley.edu
Mon, Apr 16, 2012 11:57 PM
Ray,
Do you know if we still need to use the tenant in t the subject and object
document type in relations?
Susan
Hi Everyone,
I have an update to this message. I've been updating one of our
deployments to use the latest collectionspace code checked out of git, and
I've found that the opposite of what is stated below is now true. For 2.3,
it looks like it will no longer be necessary to change
services-tenant-singular in the app layer. In fact, for related records to
show up properly in the sidebar, you must not change it. This is a good
thing, as it simplifies configuration, but you will need to be aware of it
when you upgrade to 2.3.
Thanks,
Ray
On Jan 5, 2012, at 4:59 PM, Ray Lee wrote:
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-tenant-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
Ray,
Do you know if we still need to use the tenant in t the subject and object
document type in relations?
Susan
> Hi Everyone,
> I have an update to this message. I've been updating one of our
> deployments to use the latest collectionspace code checked out of git, and
> I've found that the opposite of what is stated below is now true. For 2.3,
> it looks like it will no longer be necessary to change
> services-tenant-singular in the app layer. In fact, for related records to
> show up properly in the sidebar, you must not change it. This is a good
> thing, as it simplifies configuration, but you will need to be aware of it
> when you upgrade to 2.3.
>
> Thanks,
> Ray
>
>
> On Jan 5, 2012, at 4:59 PM, Ray Lee wrote:
>
>> 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-tenant-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
>
PS
Patrick Schmitz
Wed, Apr 18, 2012 4:14 PM
IIRC, services tenant singular is in fact the document type name. And yes,
for relations, we fixed the code that was referencing per-tenant specific
doc types, to use the generic supertype instead. When we fix that, I did not
know that this configuration setting was implicated, or I would have said
something. Apologies for any confusion.
Patrick
Hi Everyone,
I have an update to this message. I've been updating one of our
deployments to use the latest collectionspace code checked
and I've found that the opposite of what is stated below is
For 2.3, it looks like it will no longer be necessary to change
services-tenant-singular in the app layer. In fact, for related
records to show up properly in the sidebar, you must not change it.
This is a good thing, as it simplifies configuration, but you will
need to be aware of it when you upgrade to 2.3.
Thanks,
Ray
On Jan 5, 2012, at 4:59 PM, Ray Lee wrote:
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
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
(e.g. base-collectionobject.xml). In it, you need to change the
content of the services-tenant-singular element.
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-tenant-s
ingular>
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
add a record with a schema extension as a related record
else, it will fail to appear in the related records list
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
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
IIRC, services tenant singular is in fact the document type name. And yes,
for relations, we fixed the code that was referencing per-tenant specific
doc types, to use the generic supertype instead. When we fix that, I did not
know that this configuration setting was implicated, or I would have said
something. Apologies for any confusion.
Patrick
> -----Original Message-----
> From: talk-bounces@lists.collectionspace.org
> [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of
> sstone@socrates.berkeley.edu
> Sent: Monday, April 16, 2012 4:58 PM
> To: Ray Lee
> Cc: CollectionSpace Talk List
> Subject: Re: [Talk] services-tenant-singular
>
> Ray,
>
> Do you know if we still need to use the tenant in t the
> subject and object document type in relations?
>
> Susan
>
> > Hi Everyone,
> > I have an update to this message. I've been updating one of our
> > deployments to use the latest collectionspace code checked
> out of git,
> > and I've found that the opposite of what is stated below is
> now true.
> > For 2.3, it looks like it will no longer be necessary to change
> > services-tenant-singular in the app layer. In fact, for related
> > records to show up properly in the sidebar, you must not change it.
> > This is a good thing, as it simplifies configuration, but you will
> > need to be aware of it when you upgrade to 2.3.
> >
> > Thanks,
> > Ray
> >
> >
> > On Jan 5, 2012, at 4:59 PM, Ray Lee wrote:
> >
> >> 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-tenant-s
> >> ingular>
> >>
> >> 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
> >
>
>
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.c
> ollectionspace.org
>
