Hi Devin,
On Jun 17, 2008, at 10:03 PM, Devin Bougie wrote:
[ . . . ]
Many thanks, Nick. This cleared up my misunderstanding.
You're welcome :-)
Do you recommend leaving edsrn as DEMOART_RN, or does it make more
sense to update all instances of "DEMOART" to the new doctype ID?
"edsrn" refers to the name of the file (in the submission's working
directory) in which the generated report number is stored, so it would
be cleaner if it takes the name of the new document type (for example
NEWDOCTYPE_RN). However, it's worth noting that the edsrn parameter
is shared with other websubmit functions. You're seeing it in use for
the Report_Number_Generation function here, but in the modify
bibliographic information step, for example, it's used in the
"Get_Report_Number" function and in that case, there is a field in the
MBI submission form into which the user enters the report number of
the document she wants to modify, and from which the Get_Report_Number
function reads the value - as instructed by the edsrn parameter.
So - the short answer is that if you change the value of this
parameter, you should also make a field "NEWDOCTYPE_RN" (or whatever
name you want, really) and use it in place of "DEMOART_RN" wherever it
occurs in your new submission.
Currently, using websubmit-admin's "clone a document type" feature is
somewhat analogous to making a python shallow copy of a list. The new
clone has all of the same parameter values as its master, and refers
to the same field element descriptions. That is to say that if
DOCTYPEA has a field DOCTYPEA_TITLE and you clone that document type
into a new one (DOCTYPEB), DOCTYPEB will refer to DOCTYPEA's
DOCTYPEA_TITLE field (and other fields), if you know what I mean.
Although sharing fields between different document types is sometimes
desirable, it may interest you to know that we prefer not to do it.
Instead, we prefer to give each document type its own fields. This
way, if we change the definition of a field in one document type (e.g.
making it longer, adding another option to a select list, etc) the
change doesn't affect the other document type forms. If you look at
the four demo document types in the Invenio demo site, you'll see that
they all have their own fields.
You'll also notice that we have chosen to name all fields according to
the convention "DOCTYPE" + "_" + "FIELDNAME". This makes it easy for
us to select all fields relating to a document type, and then to
manipulate them in some way. Currently, the way that we'd "clone" a
document type would be by dumping everything relating to it from the
database, replacing the doctype name with the new document type's name
(and doing any other editing as desired), then uploading the new
fields back to the database.
Here's an example of what we do (cloning the "DEMOART" document type):
## Dump field element descriptions:
mysqldump --skip-opt -u root -p -t "-wname like 'DEMOART_%'"
cdsinvenio sbmFIELDDESC \
> sbmFIELDDESC.sql
## Dump Fields "instances" (as they appear on your document type's
submission forms:
mysqldump --skip-opt -u root -p -t "-wsubname like '%DEMOART'"
cdsinvenio sbmFIELD \
> sbmFIELD.sql
## Dump the document type description:
mysqldump --skip-opt -u root -p -t "-wsdocname = 'DEMOART'"
cdsinvenio sbmDOCTYPE \
> sbmDOCTYPE.sql
## Dump the functions used by the document type:
mysqldump --skip-opt -u root -p -t "-wdoctype = 'DEMOART'" cdsinvenio
sbmFUNCTIONS \
> sbmFUNCTIONS.sql
## Dump the parameter values for the document type:
mysqldump --skip-opt -u root -p -t "-wdoctype = 'DEMOART'" cdsinvenio
sbmPARAMETERS \
> sbmPARAMETERS.sql
## Dump the categories of the document type:
mysqldump --skip-opt -u root -p -t "-wdoctype = 'DEMOART'" cdsinvenio
sbmCATEGORIES \
> sbmCATEGORIES.sql
## Dump the "actions" supported by the document type (SBI, MBI, etc):
mysqldump --skip-opt -u root -p -t "-wdocname = 'DEMOART'" cdsinvenio
sbmIMPLEMENT \
> sbmIMPLEMENT.sql
For each of the files, you can then use your favourite text editor (or
shell command) to replace the "DEMOART" values with the new document
type ID (you could also edit other details, as needed - maybe you'd
like to change the labels that accompany fields on the submission form
pages in sbmFIELD.sql for example . . . )
Once you have made your changes, you can upload them to the database.
For example:
(**Quick warning: be careful when manipulating data in this way - make
sure that you changed everything correctly. E.g. you don't want your
new doctype's fields appearing on the submission forms belonging to
the document type from which it was cloned.)
$ cat sbmFIELDDESC.sql | /opt/cdsinvenio/bin/dbexec
$ cat sbmFIELD.sql | /opt/cdsinvenio/bin/dbexec
$ cat sbmDOCTYPE.sql | /opt/cdsinvenio/bin/dbexec
$ cat sbmFUNCTIONS.sql | /opt/cdsinvenio/bin/dbexec
$ cat sbmPARAMETERS.sql | /opt/cdsinvenio/bin/dbexec
$ cat sbmCATEGORIES.sql | /opt/cdsinvenio/bin/dbexec
$ cat sbmIMPLEMENT.sql | /opt/cdsinvenio/bin/dbexec
After this, all you'd just need to copy the bibconvert templates (for
creating/modifying records - DEMOART.tpl, DEMOARTcreate.tpl,
DEMOARTmodify.tpl - NEWDOCTYPE.tpl, NEWDOCTYPEcreate.tpl
NEWDOCTYPEmodify.tpl in this example) from those of the old document
type and substitute the old doctype ID string in the field names in
them for the new one. Copy the new templates to /opt/cdsinvenio/etc/
bibconvert/config .
In the future, we may make inveniocfg capable of doing this for you,
or perhaps we'll update the "clone" functionality of websubmit admin
to do this "deeper" cloning instead, but for now, I hope the above
information is useful to you.
Many best wishes,
Nick.
