Still catching up after the break...
Created a job on the new build server in preparation for automating a bunch of stuff. Right now it's only running diagnostics.xsl, but it will eventually do a lot of stuff. I had to rewrite a chunk of diagnostics.xsl, because it was done in XSLT3 with maps, and we only have SaxonHE on the server, of course. It now runs under XSLT2, albeit a bit slower.
We now have a working job on our HCMC Jenkins box which builds the static Mariage site, thanks to anonymous read-only checkout from SVN.
Did a little work last night and some more this morning to get this running and tested. I had to do some file re-organization to handle issues around relative paths with nested includes, but everything seems to be fine on the test database. My next task is to roll this out to the dev database, assuming I have permission for that.
Started work on a read-only interface (with an infrastructure for other permission levels if required) for JSR's upcoming class. This has involved some reorganization of file locations as well as the actual implementation. I think I'm about half-way through, and it looks like it'll work fine.
Finalizing an Issue 8 article for encoding, and doing some admin.
First day back, catching up.
Three weeks vacation just over (July 13 to August 4, Aug 3 was a stat). Still haven't added any vacation for 2015 yet.
Several phone calls with BS today dealing with a variety of issues:
- Currently, we suggest that images for specific archival descriptions be uploaded using the More / Link Digital Object button/menu. This allows you to upload only a single file. He would like to supply multiple files, but this can only be done by creating subitems (which he designated as "Part"s), which then show up as search hits alongside regular records. There seems to be no way around this. I suggested that if multiple images are necessary (to show for instance two facets of an object), they might be created as a single composite image with an inset.
- This has led us to more detailed discussion of upload limits and the number of images we can accommodate; I've written to HR to see what our space limits might currently be.
- SAR created some new users in response to requests, but didn't have full details on what permissions they needed, so they were all created as general editors. This is a bit risky, since it allows people to edit or delete descriptions belonging to other repositories. I've now created an appropriate array of groups and assigned the correct permissions, as well as adding two more new users to the set, and removing rights from one user who has apparently left the project.
I started work on the bug reported in the previous post, by reproducing the structure required in the Potluck test db and trying to confirm what was happening. I couldn't reproduce it at all. So I went back to the original Landscapes local_classes.php file and searched for anything that might be anomalous. What I found was that the two fields in the owner table that linked to the titles as owner and seller had the same field name. That was obviously wrong, and was a good candidate for causing all the issues we'd seen. I fixed the issue in the dev db and tested as thoroughly as I could, without being able to trigger any errors, so I've now asked the field team to test the dev db, and if they can't break anything, we'll port the fix to the live db (and obviously test again there).
If this is fixed, it will free me to implement read-only access as requested by JSR.