[sakai-core-team] Content Review Improvments for 10

[Bryan Holladay]

I don't think it's wise to introduce these changes into a maintenance
branch. All of the following projects must be updated in someones instance
at the same time, otherwise the tools will be broken: Assignment,
Assignment2, Content-Review, VeriCite Impl, TurnItIn Impl, and
ConterReviewFederated. You'll also need to update the TurnItIn impl 10.x
branch (prob cut it from trunk).

As far as testing goes, yes, they have been tested a lot and in production
with several institutions. You haven't missed anything, just those 6
projects. As for the mock content-review impl, I don't think that's
necessary since the federated impl handles the case of no content review
impls just fine. Only advantage would be for logging. I wouldn't use
federated impl to do logging since you'd have to change how it works (e.g.
return "true" for  isSiteAcceptable, which would prob then break b/c there
are no implementations of content-review).

-Bryan

On Thu, Nov 13, 2014 at 12:56 PM, Matthew Jones <matthew at longsight.com>
wrote:

> Hi Bryan,
>
> We were talking on the call today about getting the improvments on
> https://jira.sakaiproject.org/browse/SAK-26318 and the all of the related
> sub-tasks in for 10.x for either 10.3 or 10.4. I know that whoever picked
> this up would also have to update Assignment 2 (if they're running it) and
> the Turnitin and Vericite Impls (if they are also running those).
>
> It seems like these all have been tested enough and looks like we're
> running on some clients locally so they are low risk and would be preferred
> for anyone running content review, just wondering what you think and if I
> missed any impls or non-core changes that are not listed as sub-task or
> we'd have to mention in the release notes.
>
> And I know we worked on a mock content-review-impl at one time that just
> prints log messages. I think it would be nice to include that in the core
> Sakai code so it can easily be switched over to for testing. Was that
> checked in anywhere? Either that or maybe when we bring over the default
> federated impl we can add in an option for more logging if the there are no
> defined providers.
>
> Like
>
> if (provider != null)
>
> //Run the provider
>
> else
>
> //Print a log (debug?) message about how it would run the provider, but there is no provider available
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-core-team/attachments/20141113/6dc71266/attachment.html