I think the item-view version should work in the item-list context, assuming
all variables have been defined. At least on our environment, I’ve customised
the thumbnail display with some hefty logic and had no trouble copy-pasting the
same code from item-view to item-list.
Of course the only
Marking a bitstream as "primary" fixes this -- unfortunately, we have 300+
items in the collection that have this problem.
I was hoping that we could find a "code" method to resolve this more
quickly... unfortunately, that's looking like it may not be possible...
Alex
On Tuesday, 4 December
I have experienced a similar issue in the past.
If you mark one of the bitstreams as primary (on the item edit screen), do
you see more consistent results?
On Tue, Dec 4, 2018 at 10:56 AM Alex Fletcher
wrote:
> Really delayed followup, as other priorities came up (typical).
>
> Comparing the
Really delayed followup, as other priorities came up (typical).
Comparing the two, they really come down to the src attribute.
item-view.xsl has it presented as:
while item-list.xsl has it as:
It looks like the major difference is in the 'mets:file" call. The question
I have is -- will the
Dear All,
I would like to create a group that could submit an item and it isn't an
admin. ( I don't want that some user remove a collection or other)
I have created a gruop "Staff" but when I go in authorization and choose a
community (MATH), if I add this group to "MATH" with the policy
> Dear all,
>
How can we enable CSRF in DSpace login and other input forms?
While doing a security audit we got the following feedback.
problem:User Account Hijack via CSRF
URL: http:///profile
Risk: VulnerableHigh
Suggestion: Implement Tokenization
How can we solve this problem?
Hello Hardy,
actually anyone is in the anonymous group, even if not logged in. I would not
give anonymous submit right.
Submission without an eperson would not work, either
Wouldn't that be the use case for a special group see
https://wiki.duraspace.org/display/DSDOC6x/Authentication+Plugins
