[EP-tech] Unknown entries in creator browse

[alan.stiles at open.ac.uk (Alan.Stiles)]

Good memory ? looks like I missed that email conversation first time around.
I think we surmounted the problem by using a local grouping function on the person view, which built on the [creators_id, editors_id] for internal users in the same way as your view.  The grouping function excludes entries from the sections hash of arrays it returns, where it can?t find the creators_id (or editors_id) in the user table.
Alan

From: eprints-tech-bounces at ecs.soton.ac.uk [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Matthew Kerwin
Sent: 13 September 2017 00:50
To: eprints-tech at ecs.soton.ac.uk
Subject: Re: [EP-tech] Unknown entries in creator browse

Wow, this discussion was ringing a lot of bells for me.  I've (finally) managed to dig up this old thread: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/2014-December/003730.html

If anyone's interested, I ended up hacking
EPrints::Update::Views::fieldlist_sizes
 to let me specify my own top-level SELECT function for the view.

Also, I recently did this: https://github.com/eprints/eprints/commit/2f9d827397680279d0a59808f8559306d0be8bb3

...which changes the way 'allow_null' interacts with 'multiple?' fields.  It may be related, but that was more for making sure
allow_null=>1
works, rather than
=>0
.

?Cheers
--
  Matthew Kerwin
  http://matthew.kerwin.net.au/
-- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302). The Open University is authorised and regulated by the Financial Conduct Authority in relation to its secondary activity of credit broking.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20170913/198975bf/attachment.html