[Dspace-general] Week 5: Submission process

[Graham Triggs]

Dorothea Salo wrote:
> 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. :)

Yes, that's exactly how it works.

> 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.

But there are other scenarios:

Eperson DOES NOT want task, hits their browser's back button

Eperson DOES NOT want task, and clicks on any other link in the navigation

Eperson DOES NOT WANT task, closes browser and walks away

etc.

What happens in those cases if the 'accept task' screen doesn't exist? 
The task is no longer in the pool, so nobody else can choose to take the 
task.

> In other words, keeping the "accept task" screen doesn't actually save
> any work for the eperson who doesn't want a given task!

Quite, but that's not what it's there for!

> 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").

No, until you 'perform the task', the task is still in the state that it 
was in before you clicked 'take task' - ie. it is still in the pool.

It would be more accurate if the button said 'view task', and then the 
next page have 'take task'.

> 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.

Well, you could hook into the SessionListener, and wait for the 
sessionDestroyed(), but an expiring session can't really be taken to 
mean that an eperson does not want a task and/or that it can be returned 
to the pool. (There may be a very good reason why they've taken it, to 
prevent others from working on it).

And you have all sorts of potential issues if the web server crashes, etc.

> 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.

The state of the task isn't important to the performer, but it is 
important to the 5 other people that you've set up to be able to review 
content in that collection. They don't want to be reviewing an item that 
someone else is already working on. It may be important to you, if 
you've noticed a submission that you don't want any of them working on 
(but which you don't simply want to reject).

The biggest headache is dealing with things that you can't possibly know 
- for example, how do you trap the case where a user has gone off to a 
different page? OK, you may be able to detect that they are looking at 
another page, but what's to say they aren't doing that in a different 
tab, and are still keeping the review task open?

G

 
 
This e-mail is confidential and should not be used by anyone who is not the original intended recipient. BioMed Central Limited does not accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of BioMed Central Limited. No contracts may be concluded on behalf of BioMed Central Limited by means of e-mail communication. BioMed Central Limited Registered in England and Wales with registered number 3680030 Registered Office Middlesex House, 34-42 Cleveland Street, London W1T 4LB
This email has been scanned by Postini.
For more information please visit http://www.postini.com