Regression in 2.7.x: CSV information object export no longer respects 'levels of description' selections

[Brandon Uhlman]

Hi, all.

 

The AtoM archival description CSV export allows you to optionally include descriptions which are descendants of the target description(s), and additionally to choose to export all descendant levels of description or only specific descendant levels of description.

 

 

After migration of our AtoM staging environment from 2.6.4 to 2.7.1, if you deselect “include all descendant levels of description” and choose one or more of the levels of description from the selector field, the selections are not respected, and instead all descendant levels of description are exported.

 

From the log of the export job, it appears that the levels of description are being passed:

 

[info] [2023-03-31 10:34:48] Job 2415581 "CSV export": Parameters: {"params":{"fromClipboard":true,"slugs":["anne-innis-dagg-fonds"]},"current-level-only":false,"public":false,"objectType":"informationObject","levels":{"639833":null,"221":null,"224":null},"name":"CSV export","id":"2415581"}

 

…and it appears the parameter is being correctly passed to the XML export job as well:

 

[info] [2023-03-31 10:37:06] Job 2415583 "XML export": Parameters: {"params":{"fromClipboard":true,"slugs":["anne-innis-dagg-fonds"]},"current-level-only":false,"public":false,"objectType":"informationObject","levels":{"639833":null,"221":null,"224":null},"name":"XML export","id":"2415583"}

 

...but the XML export correctly exports only the targeted levels of description and the CSV export doesn’t.

 

I *think* the issue might be in /lib/job/arInformationObjectCsvExportJob.class.php (https://github.com/artefactual/atom/blob/stable/2.7.x/lib/job/arInformationObjectCsvExportJob.class.php), at line 61. It triggers the export of descendant levels of object if the ‘current-level-only’ parameter isn’t selected, and is supposed to include the desired levels of description as a parameter to a getDescendantsForExport() function call. The code in qa-2.x (the development repo) populates this with a field called $options, but that field isn't defined anywhere in that function, or even anywhere in the class.

With some judicious debugging statements, I was able to figure out that "levels" was an array defined as a child attribute of $this in that function, but even hand-creating an array in place of $options that included what I thought were the appropriate values from $this didn't seem to work.

I'm hoping that a developer or a maintainer might be able to put some eyes on this, or at least start tracking it as a bug. I suspect I'm close to a fix, but the exact details of it elude me.

Brandon

 

 

Brandon Uhlman, Senior Systems Administrator and Analyst

Digital Initiatives, University of Waterloo Library 

Phone: (519) 888-4567 ext. 43750

 

[Dan Gillean]

Hi Brandon, 

Thank you so much for providing useful details for us to reproduce, as well as the results of your own investigations! I've successfully reproduced this locally, and have filed a bug ticket for our maintainers to review, here: 

• https://projects.artefactual.com/issues/13659
  

We hope to address this in an upcoming release. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/YT2PR01MB4318B6C649BDE65A29A32272FD959%40YT2PR01MB4318.CANPRD01.PROD.OUTLOOK.COM.

[Brandon Uhlman]

Thanks, Dan.

Is the best practice for bug reporting from non-Artefactual folks to report it here? Or is there a way for external folks to get access to Redmine if they are frequent fliers (having spilled my fair share of ink on bug reports)?

~B

[Dan Gillean]

Hi Brandon, 

TL;DR: For now, reporting issues here is the best method. This may change in the future. 

We're kind of in the process of transitioning the responsibility for managing the AtoM project internally (with the new Maintainers team being a part of this). One of the things in the works is, like Archivematica did before, move the AtoM project's issue management off of Redmine. We'll likely use GitHub issues going forward - though the exact details of when, how, and what access public users have are all still TBD.

Also, in addition to a bunch of bots spamming the signup, one of the reasons we originally closed Redmine issue creation to public users was because of too many low effort bug reports - not enough details to reproduce, local configuration or deployment issues being reported as application bugs, etc. In the end, it was useful for Artefactual staff to make sure that we could reproduce the bug in a vanilla AtoM installation that followed the recommended installation instructions before calling something a bug - and it was often helpful to determine if the bug was still present in the current development branch, or just the most recent stable branch (i.e. has this been fixed already). Not everyone puts as much thought and effort into investigating an issue before coming to the forum or trying to file a bug report as you do! 

Given that we can add templates and like to GitHub issues, I suspect that such a move will allow us to open things up more than they have been with Redmine - but we'll see; it's not up to me! Either way, we will share more information on this when there's news to  report, so ... stay tuned! 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/c4151c38-bed4-4ede-8889-e385c507fe55n%40googlegroups.com.