WE HAVE SUNSET THIS LISTSERV - Join us at collectionspace@lyrasislists.org
View all threadsThanks Aron for these approaches. We'd also been thinking along the lines of specially created reports, but a web app built on the Services API could be more flexible and more importantly avoid the SQL :-)
Cheers,
Chris
-----Oprindelig meddelelse-----
Fra: aronroberts@gmail.com [mailto:aronroberts@gmail.com] På vegne af Aron Roberts
Sendt: 23. april 2013 21:52
Til: Christopher Pott
Cc: Chris Hoffman; talk@lists.collectionspace.org List
Emne: Re: [Talk] Proposal for a contribution to v3.2.3
I wrote:
You could likely do this [cross-record-type search to return Cataloging records that reference persons who were alive during a certain era] with:
a) A report
b) A batch job
There's another option, as well:
c) A web-based app ("webapp")
In the UC Berkeley CollectionSpace deployments - two museums launched
in summer 2012 and a third to be launched this month - there are a
fair number of 'webapps' written for special purposes such as these.
They've been written in an in house-developed Python-based framework,
but now are being transitioned to Django, a widely used framework
(also based on Python). My impression is that we have lots to share
with the community about this, once we can get our focus a bit out of
museum launches and upgrades, and release deadlines.
It's also worth mentioning that the search you've mentioned, Chris,
might conceivably be achievable via two existing Services REST API
calls (as yet untried):
Aron
On Tue, Apr 23, 2013 at 12:14 PM, Aron Roberts
aron@socrates.berkeley.edu wrote:
On Tue, Apr 23, 2013 at 1:32 AM, Christopher Pott
Christopher.Pott@smk.dk wrote:
The kind of use case we have in mind is where
you could search for all cataloging records containing a reference to a
person who was living during a certain period, for example.
If you have relatively few of these rather involved
'cross-record-type' searches - in this case, "return the CSIDs of
CollectionObject/Cataloging records which contain a reference to a
Person record in one or more of their fields, where a specific date or
date range of interest falls within the span of the birth/death dates
of that person" - but the ones you do have are important and/or
frequently used, you could likely do this with:
a) A report
b) A batch job
If you needed the records resulting from that search to be added to
a Group, for instance, so you could perform actions on them, a batch
job might be able to do this. I don't recall off-hand if there's some
way to pass one-time parameters to a batch job, however, much as you
now can pass them to reports.
Aron
Will your
contributions support this kind of functionality?
This specific button, we don't entirely understand, as the related records
tabs and the links on the right side bar appear to already provide these
same results. In the example you provide, wouldn't you get the same results
by clicking the 'cataloguing' tab? Or is the idea that you have a
requirement to see all record types together (cataloguing + media + loan in
etc) in one list in order to achieve a quicker overview (and if so, don't
you already get this in the 'Action Records' links)?
BTW thanks for shouting out with these proposals.
Cheers,
Chris
Fra: Talk [mailto:talk-bounces@lists.collectionspace.org] På vegne af Chris
Hoffman
Sendt: 16. april 2013 22:44
Til: talk@lists.collectionspace.org List
Emne: [Talk] Proposal for a contribution to v3.2.3
Hi all,
UC Berkeley is building some functionality for local deployments that we
think would be a good addition to the core system. We're calling this the
"Show related objects" button. What it will do is this: From a procedure
record (such as a Loan Out) that has related Collection Objects, the user
will be able to click a "Show" button. Clicking the "Show" button will
redirect the user to the Advanced Search results screen with the related
Collection Objects listed as if one had done a search for them. From that
point, the user can navigate through those Collection Objects. Our
production deployments are eager to have capabilities that help them process
related objects in more efficient ways.
This functionality is documented in the following Jira and its subtasks:
http://issues.collectionspace.org/browse/PAHMA-762
The UI mockup is attached to:
http://issues.collectionspace.org/browse/PAHMA-766
UC Berkeley proposes that this change be done in the next 2-4 weeks and be
built as version 3.2.3 of CollectionSpace. Please send comments or questions
to the list or to me. We'll wait to hear from Megan to see if the project
is willing to accept this contribution.
Regards,
Chris
P.S. The "Show Related Objects" button will be made even more powerful when
UCB contributes some local work done months ago. We will try to contribute
that within the next six months.
Chris Hoffman, Ph.D.
Manager of Informatics Services
IST-Research Information Technologies, UC Berkeley
510-642-9643
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
This is really useful, thanks Jesse.
Cheers,
Chris
Fra: Jesse Martinez [mailto:mjesse@gmail.com]
Sendt: 23. april 2013 22:25
Til: Aron Roberts
Cc: Christopher Pott; talk@lists.collectionspace.org List
Emne: Re: [Talk] Proposal for a contribution to v3.2.3
This reminds me of some of the documentation I put together for MMI some months back.
In these wiki pages are some techniques of creating complex API calls and such. Mind you, while much of this may be specific to MMI's schema and deployment the basic workflow should stay the same. It's old though -- for v2.6 -- and there may be better or improved ways to handle some of the workflow issues especially with respect to filtering multiple API calls.
http://wiki.collectionspace.org/display/deploy/MMI+Collection+Browser+Object+Schema+for+2.6
http://wiki.collectionspace.org/display/deploy/MMI+Collection+Browser+Authority+Term+Schema+for+2.6
Hope this can help,
On Tue, Apr 23, 2013 at 3:51 PM, Aron Roberts <aron@socrates.berkeley.edumailto:aron@socrates.berkeley.edu> wrote:
It's also worth mentioning that the search you've mentioned, Chris,
might conceivably be achievable via two existing Services REST API
calls (as yet untried):