On Mon, Sep 15, 2008 at 9:39 AM, Graham Triggs <[EMAIL PROTECTED]> wrote:
> You are right, it is an easy fix - it took me minutes alter the metadata > entry JSP to add little red stars next to any field marked as <required> > in input-forms.xml. Just for clarification: if input-forms.xml changes to make different fields required or not, your JSP fixes the input screens automagically? That's obviously the ideal. :) Manakin folks: how much does DRI know about what's in input-forms.xml? Is it possible for a theme to do this work, or does an Aspect have to be rewritten? > This is a tricky one - the information in the pool listing isn't > necessarily enough for someone to decide if they are going to do the > task. So if they take it, they have to return it to the pool or nobody > else can work on it. Well, yes, but look at the clickstream here. We have four cases: eperson does or doesn't want a task, crossed with "accept task" screen existing or not. If eperson DOES want task, and "accept task" screen DOES exist: Eperson takes task, eperson accepts task. Two clicks. If eperson DOES want task, and "accept task" screen DOES NOT exist: Eperson takes task. One click. If eperson DOES NOT want task, and "accept task" screen DOES exist: Eperson takes task. Eperson rejects task. Two clicks. If eperson DOES NOT want task, and "accept task" screen DOES NOT exist: Eperson takes task. Eperson clicks "return task to pool." Two clicks. In other words, keeping the "accept task" screen doesn't actually save any work for the eperson who doesn't want a given task! It also creates a whole JSP/XMLUI section to maintain for developers (and, if I understand correctly, a whole state for a task to be in: "taken but not done yet"). I'm sensitive to the scenario in which an eperson who doesn't want a task forgets to return it to the pool, but my fix for it (if possible) would be to return the task to the pool automatically once the eperson's session ends. If they want the task later, they can pick it up again from their My DSpace page... and I note that this solution would help deal with the "marooned task" problem as well. Ideally, the "return task to pool" button would be relabelled or eliminated, because the state of a task is really DSpace-internal housekeeping, not something that's important to the performer of the task. In this scenario, failure to perform the task, or navigation away from the task toward something else, would signify "return task to pool" to DSpace. I don't know how much programming hassle that would create, I'm afraid; the workflow code has made my head hurt whenever I've looked at it. Dorothea -- Dorothea Salo [EMAIL PROTECTED] Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 _______________________________________________ Dspace-general mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/dspace-general
