[Dspace-general] Week 5: Submission process

[Dorothea Salo]

> Yes, that's exactly how it works.

Beautiful!

> But there are other scenarios:
>
> Eperson DOES NOT want task, hits their browser's back button

Task returns to pool on session end.

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

Task returns to pool.

> Eperson DOES NOT WANT task, closes browser and walks away

Task returns to pool on session expire.

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

I could go for this, as long as there's a button next to "view task"
that says "do task." That still lets me skip the argh-making "accept
task" screen.

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

Open call: How often does this happen? To me, it just doesn't -- I'm
usually the only reviewer on a collection. However, if this must
happen, I'd prefer a "reserve task" button to there *always* being an
extra click when I just want to do the gosh-darn task!

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

Always the case.

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

Again, I'm fairly convinced these are edge cases at best, nonexistent
cases at worst; I have *never* taken a task just to keep it away from
somebody else. Commentary from others?

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

Hm, yes, I see the difficulty there; I've had more than one DSpace tab
open, er, more than once. I guess waiting for session end (and having
some kind of cleanup mechanism in case of webserver crashes) is the
only thing that will work consistently.

Writing that jogged loose something else: the collection-creation tool
should have an easy hook into eperson creation. I make a *lot* of
collections where I have to stop in the middle because the epeople
related to the collection are brand-new and I have to hit the admin
interface to create them. Ideally (there's that word again), this
would happen automagically -- that is, I pop in an email address,
DSpace checks to see if it is a recognized eperson, and if it isn't, I
am taken to the edit-eperson screen (with an added "oops, typo, I
meant somebody else!" option). Added wrinkle: ideally, community
admins should be able to create collections; ought they be able to add
epeople as well?

Dorothea

-- 
Dorothea Salo                dsalo at library.wisc.edu
Digital Repository Librarian      AIM: mindsatuw
University of Wisconsin
Rm 218, Memorial Library
(608) 262-5493