Open dustymc opened 1 year ago
Sounds awesome - when do we start developing code tables?....
when do we start developing code tables?
Before anything else, that's why I put the table definitions in the Issue; what can be moved? (My without-looking answer might be "whatever's NULLable.")
My without-looking answer might be "whatever's NULLable."
I agree in principle, but making nearly everything an attribute means that some things will just get ignored (I mean, they probably are now, but putting them one step further down the chain makes it even more likely!).
seems like a great candidate and having two attributes (one that is "curatorial - aka not viewable by the public, which I am bringing up due to a comment by @AJLinn about making accessions public)
public remarks - information related to the transaction that should be publicly available private remarks - curatorial information related to the transaction that should not be publicly available
trans_date closed_date received_date due_date return_due_date lenders_loan_date
transaction processing history - the date a particular event in the transaction occurred categorical values for "date type" with the date in the determined date field:
https://github.com/ArctosDB/arctos/issues/4316
estimated part count - an estimate of the number of objects (parts) to be included in the transaction estimated record count - an estimate of the number of catalog records to be included in the transaction
https://github.com/ArctosDB/arctos/issues/6853 These seem like they could be automated and included on the transaction page:
record count - number of catalog records included in the transaction returned count - number of objects included in the transaction with disposition = in collection on loan count - number of objects included in the transaction with disposition = on loan used up count - number of objects included in the transaction with disposition = used up
lenders_trans_num_cde - the identifier assigned by the lending institution. or should this be more generic and instead be:
other transaction identifier - any identifier assigned to the transaction in addition to the transaction number of record in Arctos. Determiner should be the issuing agent.
OK - that's my thoughts for now....
just get ignored (I mean, they probably are now
Yes, that's the split - don't think it matters HOW they get ignored....
dates
If dates should DO STUFF then they should probably remain "fields" - querying for "whateverdate past whatever event..." and getting 372 different answers (attributes are always in "zero or more" relationships to their parent) would be difficult to work with. (That is, were I responsible for loans I'd want loan.due_date sending me notifications - but I'd have been screaming about it being NULLable for a while too, so ??)
automated
Not really, there's no connection between disposition and loan. Send an item on loan, get it back, repeat 40 more times, send it out again, the first loan now has the item with a disposition of 'on loan' even though that particular loan was entirely dealt with decades ago. I can get the counts easy enough, but they don't mean what you are implying.
other transaction identifier
I like it, the alternative is probably a buch of things all used once or twice, general seems appropriate here.
I like this in principle.... trying to imagine the regular usages for this. Can we add to next Issues meeting for a little more discussion/ input?
I agree ith @mkoo, add to issues meeting agenda.
For counts, I think we need perhaps three - all of which can go in attributes: 1) estimated - what you think there should be (i.e., in accessions) 2) in hand (or some other term) - what you actually have in hand for cataloging or loaning; use cases would be a) tracking material as it is prepared prior to cataloging, b) loaning uncataloged material, ... this is NEW and relates to issue 6853 3) cataloged - actual count of cataloged records, could/should be automated
CT discussion:
Going next task, I know how to do this.
Is your feature request related to a problem? Please describe.
We keep asking for weird transaction-things.
Describe what you're trying to accomplish
Flexibility (with agents and dates).
Describe the solution you'd like
Create a transaction attribute table, move some stuff to it
Describe alternatives you've considered
Don't.
Additional context
https://github.com/ArctosDB/arctos/issues/6340#issuecomment-1563251369 https://github.com/ArctosDB/arctos/issues/6853 https://github.com/ArctosDB/arctos/issues/4316
Priority Please assign a priority-label. Unprioritized issues gets sent into a black hole of despair.