Possible feature: community additional "introductions" for contributors, managers

[Mark H. Wood]

During a local discussion today, it occurred to me that it might be
useful to have additional Community and Collection metadata for
introductory text that is only relevant to contributors or managers.
These blocks would only appear to those who have rights to submit to a
container, or to manage it. They would have associated textareas on
the Community / Collection edit forms. Ideally they would be treated
as HTML fragments, similar to the Introduction, Copyright, and News
texts.

Some sites might wish to reserve write access of these fields to
internal staff rather than container administrators, so it might be
advisable to associate per-container access policies with these
fields.

While writing, I realized that it's a bit peculiar that the Site
(i.e. the instance's home page) doesn't have *any* of this sort of
thing; one has to hack on the UI code, or have access to the external
"news" text files on the server. Why *don't* we have a Site edit form
and editable text blocks on the front page?

Discussion?

--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

[Tim Donohue]

Mark,

I think it's an interesting idea. But I have a few notes to add:

1. We don't yet have the concept of permissions/rights on *individual metadata fields* (currently, if you can READ the DSO, you can read all its metadata fields, other than special cases like "dc.description.provenance" which is hidden except for full Admins).  This same idea has come up several times in different use cases, and it could be that we need to make this happen at some point (post-7.0).  But, at a quick glance, creating "blocks of text" only visible to certain user types sounds like this same thing....those text blocks would likely be metadata on a Site, Community or Collection & they'd need some sort of policy to define who can see/edit them.
2. We very well could/should have metadata on Site objects (for the homepage), as implied by your final paragraph.  I think the only reason this *didn't exist* is that the Site object itself didn't really "exist" as a full DSO until 6.x (IIRC).  It was always something hardcoded in the API layer, but now it's a full object, with its own UUID (see "site" table) and it therefore can have its own metadata.  (In DSpace 7 it's treated even more of a DSO as we are adding a default Resource Policy giving Anonymous READ to the Site)

In any case, I think these are both interesting points.  Arguably #2 above is possible to implement *now* in DSpace 7 (would need a volunteer though).  We could make this info editable on a Site object as metadata and display it on the homepage.  #1 might take more thought/work unless I'm misunderstanding your goals.

Tim

--

Tim Donohue

Technical Lead, DSpace

tim.d...@lyrasis.org

Lyrasis.org | DSpace.org

---

From: Mark H. Wood,UL 0115A,+1 317 274 0749, on behalf of Mark H. Wood
Sent: Thursday, September 3, 2020 1:44 PM
To: dspace...@googlegroups.com
Subject: [dspace-devel] Possible feature: community additional "introductions" for contributors, managers

--
All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "DSpace Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-devel/20200903184454.GA14716%40IUPUI.Edu.