Comment 4 for bug 1208093

For completeness sake on my thoughts:

I am unsure about *making* buckets from reports. I can see arguments for and against that. On one hand you get a nice clean bucket, on the other hand creating new buckets every time a scheduled report runs seems a bit excessive. And problematic if you don't tell it to include a date/time stamp in the bucket name, for that matter, or if you want to point people who don't get the report output at the bucket.

Providing an existing bucket ID and checking "does the user have permission to write to it" makes more sense to me, especially as then you can throw more than just staff client buckets at it (say, publicly linked bookbag buckets) fairly easily and the "most recent" bucket won't be constantly changing on recurring reports.

As for why I had two thoughts on the timing:

1 - When the report is run - This has direct backend DB access already so it should be faster and, hopefully, more efficient. But I would think we would need to check permissions at this point and bucket ownership would be limited to the report runner. An option to empty the bucket, or perhaps "set" the bucket to the report contents (remove things that are there but not in the report output, leaving the ones that are already there for added date purposes) could be useful for things like new materials bookbags in this case.

2 - From the report output (HTML view, specifically) - While less efficient in some ways this would allow for pick-and-choose (via checkboxes), adding to multiple buckets, or for people *other* than the report runner to add to buckets. Then a single report could be run for multiple people, and each could move things into buckets of their own. This would, IMO, also go better with making the various pieces of information into appropriate links (catalog links for bib ids, item information/editing for copies...) which could help with other staff tasks that don't lend themselves as nicely to the use of buckets.

I suppose there is also the option of *both* as I assume that adding the code to identify bucket-worthy information would be usable both in a "populate this bucket now" and in "put interface elements for populating a bucket later and other such tasks into the HTML output" and thus there would be significant overlap.