|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
John Leasia - 17-Jan-2007 13:18
Also, I would think that they shouldn't have access to it until the start time.
We've also received comments on this issue here at Michigan from our users.
Is there any planned work on this issue for 2.4 or 2.5? On our 2-3-x production build (r21164), site participants get the notification immediately, but they don't have access to the resource if it's not yet available - the URL returns a 403 forbidden error, which is what it should do.
It's possible this could be done for 2.4, but I think it's too late in the QA process to deal with it for the release. As I understand it, we need to check the release date when creating a resource and schedule a notification with the job scheduler if the release date is in the future. If there's no release date or the release date is in the past, we would send the notification immediately. We will need to consult Andrew Poland for details.
If we can't fix this for 2.4, we will alter the instruction text about the release and retract dates to explain that email notifications will go out immediately.
For hidden resources: Possibly also hide the notification option for hidden resources or only send notifications to those that have permission to see hidden resources.
Clay,
Is it possible that Stuart or Carl could work on this ticket and give me a patch to handle it? As I understand it, the proposal is that we use jobscheduler to trigger a notification in the future. But if the release date of the resource changes or the resource is moved or deleted, the previously scheduled notification would need to be deleted and a new one issued. If that's the case, it's likely that the key changes would be in the commitResource method. If the item is hidden or a release date in the future is set, the normal notification should be omitted and (in the case of a release date in the future) the notification should be scheduled. Many people consider this a critical bug. If we have a relatively low risk fix soon, we could ask to include it in 2.5. If you're not able to look at it, please assign back to me and I will set the target to 2.6. Thanks. Jim Carl,
Please take a look at this and see if you can get a patch out. The next RC is scheduled the second week of January, I believe, so the patch would be needed in time to test. From Carl Hall:
I'm detailing some last pieces of the email service functionality ( testing so that we don't double our test efforts. I'll be able to start on it into the 2.5 release. I'll be sure to update the JIRA as things progress. Thanks for reminding of this issue. Handling a deferred email has turned into a bigger problem of how to fire an available/unavailable event for resources in CHS. Since this is being handled after 2.5 has an RC, the current discussion for a temp fix is to add language to the email notification that the resource will be available on mm/dd/yyyy date. I'll include a link to the Gmane conversation as soon as Gmane picks it up.
The temporary fix Carl has produced for Sakai 2.5.0 is being tracked in
Carl, I've moved the patch with your temporary fix to
Fixed by serializing certain parts of the event and notification objects into the context of a scheduled invocation command. This context is then used when the invocation is run by the scheduler to have the same required data as if running without the delay.
[Edit: previously thought to have found a bug in CHS. The bug was in my code, so I removed the details of the issue from here] Jim, can you review these patches and merge to trunk? Thanks.
2 issues with the patches.
1. the Event patch has added methods and parameters, but there is no javadoc. IMHO there should be, expecially with a patch to a stable piece of code that is not often looked at. 2. A blocker at the moment, sorry. This binds Content to job scheduler. The job scheduler API is present in framework, but there is No impl because the impl pulls in lots of things. You should not assume the impl is present. Thats not the blocker, the following is. Parts of content are part of Kernel, and this patch pulls in jobscheduler, which will make the kernel much bigger. It is possible to add providers without the dependencies, and this has already been done in content, please follow this pattern to make certain that we dont increase the size of kernel. Have a look at the content-impl-providers package. You are probably safe putting things into modules that appear only in the full profiles in the base pom of content. This seems to have broken the trunk build:
http://saffron.caret.cam.ac.uk/continuum/servlet/continuum/target/ProjectBuild.vm?view=ProjectBuild&buildId=11439&id=1 Looks like there is something in memory that was mocking the event service so when the event service API changed the memory build failed. [INFO] Building sakai-memory-impl [INFO] task-segment: [clean, install, sakai:deploy] [INFO] ---------------------------------------------------------------------------- [INFO] [clean:clean] [INFO] Deleting directory /usr/local/continuum-1.0.3-public/apps/continuum/working-directory/1/memory/memory-impl/impl/target [INFO] Deleting directory /usr/local/continuum-1.0.3-public/apps/continuum/working-directory/1/memory/memory-impl/impl/target/classes [INFO] Deleting directory /usr/local/continuum-1.0.3-public/apps/continuum/working-directory/1/memory/memory-impl/impl/target/test-classes [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 6 source files to /usr/local/continuum-1.0.3-public/apps/continuum/working-directory/1/memory/memory-impl/impl/target/classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] Compiling 5 source files to /usr/local/continuum-1.0.3-public/apps/continuum/working-directory/1/memory/memory-impl/impl/target/test-classes [INFO] ------------------------------------------------------------------------ [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Compilation failure /usr/local/continuum-1.0.3-public/apps/continuum/working-directory/1/memory/memory-impl/impl/src/test/org/sakai/memory/impl/test/MockEventTrackingService.java:[34,7] org.sakai.memory.impl.test.MockEventTrackingService is not abstract and does not override abstract method deleteVoter(org.sakaiproject.event.api.EventVoter) in org.sakaiproject.event.api.EventTrackingService Could we have some documentation on how this works before it's merged to 2-5-x?
Also how does it affect records in the SAKAI_EVENT table and event-observing tools such as SiteStats? Carl,
Stephen needs some doc before merging, I will fix the build failiure that is currently happening in trunk. Ian This patch allows for an event to be voted on before it is processed. If any votes against an event are received, the event is not processed. The voter that is introduced with this patch will vote against an event if it is a) an add, remove or write event AND b) associated to a resource that isn't available yet. The information about the event is saved off into a separate table from SAKAI_EVENT in case that table is archived which seems to be common practice due to this table's high record count. A delayed invocation is scheduled that recreates the event based on the associated resource's availability and sends it back through for processing using the normal means (looks like the event was just fired). Before scheduling a delayed invocation, all other scheduled delayed invocation associated to the resource are removed.
This shouldn't have any adverse affect on event-watching tools as the events can be trapped/voted on before any notifications are sent out. Let me know if there any other questions or if I should cross-post the "docs" somewhere else. It seems the code will delay content.new, content.delete, etc. I don't think this is appropriate for other consumers of this event data.
For example, for a new content item, I want it indexed immediately (search events consumer) and reflected in site stats immediately (another consumer). Maybe there should be a new event, content.notify ? If the content is indexed, then the fact it exists will become apparent, although the item itself or the title will not. A search for a key word in the course will expose the fact there are items there. If they were not indexed then nothing would show.
Carl, ootb the table needs to be created using autoddl. It becomes too hairy to install Sakai if each tool has special scripts that need to be run inorder for the app to work. I bet someone on the dev list could help you or you could ping someone (Ian, Aaron, Steve G, Oliver) directly. Also, the script s in the patch need to be added to the conversion script in reference. We're got to have those two things before this can be merged into the 2.5.1 release
I'm also not convinced that the solution here is appropriate, in that in fixing one behaviour it changes other aspects of behaviour (i.e. delays propagation of content.* events, if I understand correctly). I'd like to see some discussion of that before we finalize this in trunk and consider merging to 2-5-x.
Committed the auto.ddl patch in r47474 so the table is created on startup.
Related to Also other than the issue discussed on sakai-dev about delaying events that other consumers may want immediately, perhaps some of the delayed event code here belongs in the event module rather than content? What would happen if another client had a similar use case (e.g. notification for a test/quiz not yet open) ? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Resolved
Blocker
Creating: Notification of items with release dates should be at release time
