[
http://jira.dspace.org/jira/browse/DS-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=10840#action_10840
]
Tim Donohue commented on DS-390:
--------------------------------
Detailed discussion took place in DSpace Developers Meeting on Nov 25 2009.
The general consensus was that this implementation may need further discussion.
A few potential short term solutions were presented -- and discussion also
went towards figuring out longer term options:
[15:37] <tdonohue> I'd like to call one more quick vote (again on behalf of
Stuart) for: http://jira.dspace.org/jira/browse/DS-390 - Workflow task
notification emails not available on deposits via SWORD.
[15:40] <lcs> just glancing at the patch, looks like it is being done within
the ingester; i know this is probably raising the bar more than we have time to
address now but i'd prefer to see the logic outside of ingester plugins and
done in a general way for all unattended package ingest (lni, sword,
commandline)
[15:41] <grahamtriggs> I'm not convinced it's the right approach - imho, task
notifications should always be sent on entering workflow. Any option to not do
so should be an eperson level choice
[15:43] <lcs> grahamtriggs: that works too. abolish startWithoutNotify() and
move the logic upstream.
[15:43] <grahamtriggs> And beyond that, rules based configuration for
notification of deposits by certain people (at which point, you could disable
just the generic login sword deposits)
[15:44] <tdonohue> good ideas / thoughts. Sounds like this may need some
further work
[15:45] <tdonohue> any recommendations on how to make this better?
[15:45] <Caryn> i like the idea of being able to control who gets notified when
- i'm pretty new to DSpace, so i might not be aware of options available right
now, but i would definitely like this kind of control
[15:45] <tdonohue> do we abolish startWithoutNotifiy() ? Do we leave it as is
and create a larger issue to rethink task notifications?
[15:46] <tdonohue> Caryn: thanks for your opinion!
[15:46] <mhwood> I think the idea has grown past the point at which it should
be marked, "good idea, not in 1.6.0"
[15:47] <tdonohue> mhwood - point taken. more discussion needed. :)
[15:48] <Caryn> btw - i should introduce myself - i'm from uci, where we're
working on getting an instance of dspace up in the libraries... i'm new to
dspace, but not digital archiving
[15:48] <lcs> for now, i'd say either abolish startWithoutNotifiy() or have it
call start() and make that configurable -- but defining the rules would take
time and discussion. (e.g. by collection, eperson, phase of hte moon?)
[15:49] <lcs> none of the other workflow email is configurable, is it? maybe
all this needs for now is a Big Switch, on or off.
[15:49] <tdonohue> Hi Caryn. Welcome.
[15:49] <mhwood> Yes, welcome.
[15:50] <Caryn> this was actually one of my questions... can i configure email
triggers?
[15:50] <mhwood> Do we need a Quick Fix right now, or is it better to point to
the patch and say that something more comprehensive is being designed.
[15:51] <lcs> It seems that right now the problem is some people want email and
can't get it, so a simple change and a Big Switch would fix that, and maybe Do
It Right in 1.7..
[15:51] <lcs> Caryn: welcome to the deep end of the pool.
[15:52] <tdonohue> lcs: yea, you are right there doesn't seem to be a "big
switch" -- which could be a good option.
[15:52] <Caryn> lol - so far, i'm treading pretty well...
[15:52] <Caryn> another problem is that emails are generated, and some people
don't want to see them
[15:52] <Caryn> so, a big switch would work
[15:52] <mhwood> And further on, I think we may identify several Big Switches
that would benefit from finer granularity.
[15:53] <Caryn> mhwood: agreed
[15:53] <lcs> It helps to tag emails consistently (e.g. something in the
Subject: header) so people who don't want them can have their user agent flush
htem away.
[15:53] <lcs> that is all doable now in the email templates, btw.
[15:54] <tdonohue> i'll make sure to add these good comments to DS-390 -- I
think I like the big switch idea for a simple switch...but we can always table
this and formally approve/deny it at next weeks meeting (when stuart will
hopefully also be in attendance)
[15:55] <tdonohue> Caryn: what do you mean by "some people don't want to see
them"? do you have a simple example?
[15:55] <Caryn> many of our collections are project based, so there will be a
time when as many as 100+ items are submitted in "rapid fire"
[15:56] <Caryn> the reviewers will know this is happening, and don't
necessarily need to see an email per item...
[15:56] <tdonohue> oh. I understand. So, when loading in a big batch of
content, those emails can get annoying and unnecessary
[15:56] <Caryn> i'm assuming this would be fixed by a big switch - the
submitter takes care of submitting, then notifies the reviewers that a batch of
files is ready...
[15:56] <Caryn> exactly!
[15:57] <snail> we are also facing a huge 'peak' of submissions in the run up
to the PBRF (called the RAE in the UK), one email per item will be unpleasant
[15:57] <grahamtriggs> Caryn: Some people may not want to see them, but some
people (possibly even them!) will NEED to see them, to action the notification.
Users can always set up filters in their own email accounts to delete/move
incoming messages, so it's generally better to err on the side of sending out
more, not less
[15:57] <Caryn> our programmatic setup is a little unique, so we have some
"special needs" - the filter idea is a possibility, but i know there have been
discussions about turning the notifications off...
[15:57] <mhwood> Move the notification out of the submission flow to a
scheduled task, which can batch up notifications?
[15:58] <Caryn> mhwood: that would be nice!
[15:58] <lcs> since email is inherently unreliable, isn't it better to count on
mechanisms within DSpace to keep up with changes, e.g. task pools, RSS feeds,
etc?
[15:59] <lcs> gee, wouldn't it be nice if we had an asynchronous event manager?
http://wiki.dspace.org/index.php/EventSystemPrototype
[16:00] <tdonohue> Caryn: I'm not sure if the "big switch" we are talking about
would really solve these problems yet -- though it could be related to a much
larger discussion around improving email notifications, etc. So, I think this
is a good idea worth some discussion. I'll add it as a Feature Request in our
JIRA system and attach this commentary as a note to it.
[16:00] <mhwood> I was just going to ask whether there is enough variation
among sites' needs here that we ought to have another plugin point.
[16:01] <Caryn> the big switch would be a work-around, not a complete solution.
i think there might enough variation among sites, and among collections within
sites that a tool like the asynchronous event manager might be worth the
development...
[16:01] <Caryn> imho, of course
[16:01] <grahamtriggs> there are some cases where an asynchronous event manager
could be useful, but in keeping track of task pools and dissemination via feeds
isn't one of them!!
[16:02] <lcs> with asynchronous events, we could put the submission-email
generator in an event consumer, and feed it a batch of events once a day. or
give sites the option of firing it synchronously.
[16:02] <mhwood> No, but there are ancillary processes (like sending emails, or
alternative notifications) which could be event sinks.
[16:03] <mhwood> I think the point may be that maintaining the task pools etc.
is core to DSpace's function and should be inline, while notifying people that
things are happening is peripheral and can be pulled out of the flow if it
helps us.
[16:04] <mhwood> Just a note that we've passed the formal end of the meeting
window.
[16:04] <tdonohue> yep. just about to say the same...but, I didn't want to
interrupt discussion
[16:05] <tdonohue> feel free to continue the discussion, but consider the
official "meeting" adjorned.
[16:06] <grahamtriggs> but the events are isolated incidents. so you need
special logic to batch up the notifications (which you can have with or without
an asynchronous event system). the only reason to put an asynchronous event in
is in recognising that it isn't that time senstitive
[16:06] <tdonohue> I think these are all great ideas, and it could be useful to
set aside a meeting to talk more about this topic and whether we want to look
closer at the EventSystemPrototype work , etc
[16:06] <mhwood> And maybe back up to ask, what things are we doing inline that
would be better as a separate process?
[16:07] <Caryn> so, tell me if i'm tracking, or if i'm way off... At this
point, I can't control email triggers in DSpace (they're connected to task
pools, and incorporated into the workflow). I can, however, customize the
subject line of the emails, so a typical email filter can handle them as the
recipient desires. Possible development issue for future releases, probably not
1.6.
[16:07] <lcs> anything that relies on an email notification shouldn't be time
sensitive, and ought to be considered expendable anyway.. i can just see that
some sites would want daily "digest" emails rather than one per submission.
[16:07] <mhwood> We already have stuff like the subscription emails that are
run separately.
[16:08] <Caryn> seems like that is what we should expect, right? dspace handles
the technical tracking, but we can control how our users are exposed to that
information via email
[16:08] <lcs> the synchronous event system got integrated in 1.5, and rrodgers
was thinking about adding async events as of a year ago or so; we talked about
it. fwiw.
> Workflow task notification emails not available on deposits via SWORD
> ---------------------------------------------------------------------
>
> Key: DS-390
> URL: http://jira.dspace.org/jira/browse/DS-390
> Project: DSpace 1.x
> Issue Type: Bug
> Components: SWORD
> Affects Versions: 1.5.2
> Reporter: Timo Aalto
> Attachments:
> [DS-390]_Workflow_task_notification_emails_not_available_on_deposits_via_SWORD.patch
>
>
> in
> dspace-sword/dspace-sword-api/src/main/java/org/dspace/sword/SWORDMETSIngester.java
> there is an assumption that workflow task notification emails are not wanted
> for SWORD item submits, by using WorkflowManager.startWithoutNotify(context,
> wsi) method instead of WorkflowManager.start(context, wsi).
> Switching to the WorkflowManager.start(context, wsi) method seems to be
> enough to enable the email notifications. Of course this should probably be
> configurable, maybe even in a broader context than just SWORD.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.dspace.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
