On Feb 2, 2009, at 3:25 PM, Donohoe, Mark wrote: > Bob Gobeille wrote: >> On Feb 2, 2009, at 11:23 AM, Donohoe, Mark wrote: >>> The first draft of the email notification design is ready for >>> review. >>> Please review and provide feedback. You can find it at: >>> >>> http://fossology.org/email-design >> >> >> If you run e-mail notification as an agent, presumably it will have a >> dependency on another agent (the one you want to be notified about). >> Is that right? If so, what if the other agent fails? In this case, >> dependent jobs are not run. > Ugg, good catch, this is a design flaw, will try to address it. The > issue is that the scheduler only knows what's next, not when a job (in > total) is done. So there is no way today, for the scheduler to > indicate > when all of the processing is done for a particular upload. Some > items > are set in the jobqueue table, jq_endtime and setting the > jq_end_bits. > So the Email agent could check those. > > This agent is uncovering issues with how FOSSology deals with failed > jobs.
For this discussion it helps to keep the terms straight. There are "jobs" and "jobqueue entries". A job queue entry is just a single task. One Job can have multiple jobqueue entries. So a license job, has 7 tasks (jobqueue entries), where each task is just another part of the license pipeline. It is the jobqueue that has dependencies. Job was supposed to be on top, with 1-n jobqueue entries under it. This hierarchy was butchered when we added dependencies on jobqueue entries. So a jobqueue entry typically depends on another task in a different job (as opposed to being dependent on the job) Now a typical upload may queue up 3 or more jobs, instead of the logically one job. We could make this a single job. This would make it easier to tell when the whole job is done. I haven't really thought this through though. >> The users table does have an email address but that doesn't mean that >> email notification is desired. So are you saying that you will add a >> field to indicate if email notifications should be sent by default >> (but potentially overridden during upload time)? > > Yes, I would add a checkbox for email notification and and area to > list > other e-mail addresses that want to be notified by email. Why not just keep the comma separated list, like we have now? > Bob, jq_end_bits also contains nonfatal=0x4 in addition to ok and > fail. > Do you know if we use this and what it means? I don't believe 0x4 is used. >> What tests are you including? > > Huh? I'm not sure what you are asking. I plan to write tests for > this > agent/function. Plus, all of the user pages need tests written for > them. Either Mary or I can code those. I meant, what conditions are you going to test? For example, killing a jq_pk manually, cross site scripting in the email address, ... >> Can other users subscribe to an upload so they are notified on any >> new >> analysis? Is there any user desire for this? >> > I actually don't think this is a good idea even if users wanted it. I > don't think this is a good idea as it is intrusive. Maybe I'm > analyzing > something that is sensitive and few folks are supposed to know about > it. Why should any user that has a login to FOSSology be allowed to > sign up to see the results? > > I could see signing up being OK, if we had a concept of 'Groups' or > something like that, but we don't. So for now, I'm not inclined to > look > into this. For example, let's say we start processing fedora and notifying package maintainers. I'm not saying that this is a requirement, I just think you want to make sure you don't close any doors. What reply-to are you using in the email? What subject? I think your design should list the files and tables you are going to change along with what is going to change logically. Bob _______________________________________________ fossology mailing list [email protected] http://fossology.org/mailman/listinfo/fossology
