issue 494 - hide selected fields from unauthenticated users
Tim Hutchinson
We are working on this issue:
http://code.google.com/p/qubit-toolkit/issues/detail?id=494
with relevant comments in the duplicate issue:
http://code.google.com/p/qubit-toolkit/issues/detail?id=1254
as well as a note on the usability wiki:
http://www.qubit-toolkit.org/wiki/index.php?title=Usability_review#Hide_fields_from_unauthenticated_users
So far, Wu has developed an interface to configure which fields in the
control area and the digital object metadata area are visible. These are
the only areas we wanted to deal with in the SK implementation, but
particularly since it was fields in the note area that resulted in this
feature request initially, and based on the earlier Artefactual comments
about our wish list item, I thought we should make it more general.
My original assumption was that it would be easiest/best to make all the
fields available. But I'm now I'm wondering if that makes sense. E.g.
when would you ever want to suppress title, or dates? Should that even
be an option?
Instead, I'm wondering if we should select a subset of the RAD/ISAD
fields that might be suitable for suppression. The list under option 2
on the usability wiki would be a good starting point (in addition to the
control area and digital object metadata area).
Or, is it better in some way to have all the fields listed, but disable
the check boxes for the required fields?
I know this feature has been discussed previously, so I'd be interested
in hearing whether there are reasons we should include all the fields;
or for that matter what fields that should be included.
Thanks
Tim
--
Tim Hutchinson
University of Saskatchewan Archives
301 Main Library, 3 Campus Drive
Saskatoon, SK S7N 5A4
tel: 306-966-6028
fax: 306-966-6040
email: tim.hut...@usask.ca
Evelyn McLellan
My instinctive preference is to limit the number of fields that could
be hidden. In RAD, I can't imagine circumstances under which anything
outside of the notes area and control area would need to be hidden. I
know there has been talk of hiding the custodial history field as
well, but since that field is mandatory at the highest level of
description I would be reluctant to allow users to hide it.
Evelyn
On Mar 3, 6:51 pm, Tim Hutchinson <tim.hutchin...@usask.ca> wrote:
> Hi,
>
> We are working on this issue:http://code.google.com/p/qubit-toolkit/issues/detail?id=494
> with relevant comments in the duplicate issue:http://code.google.com/p/qubit-toolkit/issues/detail?id=1254
Tim Hutchinson
I'd suggest:
- Control area (all fields)
- Digital object metadata (all fields)
- ISAD template:
- immediate source of acquisition or transfer
- appraisal, destruction and scheduling information
- notes
RAD template:
- immediate source of acquisition
- physical condition note
- conservation note
- general note
with the default to have all fields enabled.
I agree with your reservations about custodial history.
Any further thoughts?
Tim
tel: (306) 966-6028
fax: (306) 966-6040
e-mail: tim.hut...@usask.ca
web: http://www.usask.ca/archives/
Evelyn McLellan
Maybe physical storage fields as well?
Evelyn
> --
> You received this message because you are subscribed to the Google Groups
> "Qubit Toolkit Developers" group.
> To post to this group, send email to qubi...@googlegroups.com.
> To unsubscribe from this group, send email to
> qubit-dev+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/qubit-dev?hl=en.
>
>
Tim Hutchinson
Peter Van Garderen
---peter
Tim Hutchinson
This also relates to issue 764 - move /uploads to /data directory. With the current file structure for uploaded digital objects, we will likely need to upload surrogates rather than the masters, since making hi-res images relatively easy to access is a deal breaker for most institutions. It does not seem useful to provide metadata about a surrogate.
Incidentally I have been meaning to ask about that issue. The merged issue 1255 was originally flagged as critical and scheduled for 1.1. The current issue is scheduled for post-1.2. Does that indicate its priority, or the complexity of the change?
Tim
email: tim.hut...@usask.ca
Peter Van Garderen
On 03/11/2011 04:11 AM, Tim Hutchinson wrote:
> In our current implementation, images are more illustrative than objects that
> need to be described separately. Basically my reaction when I saw those details
> was that it was more information than users needed, which I will admit doesn't
> really answer the question :)
Fair enough. My preference would be to use theming to hide fields for more
cosmetic reasons and focus on fields with sensitive, administrative and security
information as ones to hide as part of this new 'show/hide fields toggle'
feature. That said, you could argue that the digital object metadata is
administrative information.
This is a tough feature to implement because everyone has a slightly different
opinion on which fields to include/exclude.
> This also relates to issue 764
> <http://code.google.com/p/qubit-toolkit/issues/detail?id=764> - move /uploads to
> /data directory. With the current file structure for uploaded digital objects,
> we will likely need to upload surrogates rather than the masters, since making
> hi-res images relatively easy to access is a deal breaker for most institutions.
> It does not seem useful to provide metadata about a surrogate.
>
> Incidentally I have been meaning to ask about that issue. The merged issue 1255
> was originally flagged as critical and scheduled for 1.1. The current issue is
> scheduled for post-1.2. Does that indicate its priority, or the complexity of
> the change?
Issue 764/1255 is a security issue. Using the Symfony default configuration
digital objects are currently posted to the /upload directory under the public
web directory. We want to move the upload directory to a more secure /data
directory outside of the public web directory. The reason that it has been
delayed is that it is technically complex (namely digital files will now likely
have to get serialized through PHP) and will require some time to implement and
test. We haven't been able to secure funding for that time yet.
Cheers,
--peter
David Juhasz
> Hi Tim
>
> On 03/11/2011 04:11 AM, Tim Hutchinson wrote:
>> In our current implementation, images are more illustrative than
>> objects that
>> need to be described separately. Basically my reaction when I saw
>> those details
>> was that it was more information than users needed, which I will
>> admit doesn't
>> really answer the question :)
>
> Fair enough. My preference would be to use theming to hide fields for
> more cosmetic reasons and focus on fields with sensitive,
> administrative and security information as ones to hide as part of
> this new 'show/hide fields toggle' feature. That said, you could argue
> that the digital object metadata is administrative information.
>
> This is a tough feature to implement because everyone has a slightly
> different opinion on which fields to include/exclude.
I my opinion, think this ^ is exactly the reason that a GUI for
selecting which fields are visible to unauthenticated users is important
- because every institution has different policies around what
information to make public.
I think we should consider theming an "advanced" option, as not every
institution has access to a CSS guru. Also, afaik the only CSS methods
that "hide" a tag ("display: none" or "visibility: none") still allow
seeing the hidden element by viewing the page source.
<snip>
--
David Juhasz,
Software Engineer
Artefactual Systems Inc.
www.artefactual.com
Tim Hutchinson
/data directory for digital objects). I was mostly asking to see if we
might be able to tack it on to our project, but I had a hunch the reason
was technical complexity tied to lack of funding :)
Tim
--
Tim Hutchinson
University of Saskatchewan Archives
301 Main Library, 3 Campus Drive
Saskatoon, SK S7N 5A4