[Contrib: Evaluation System] Question about reopening evaluation and stop-date

Aaron Zeckoski azeckoski at unicon.net
Mon Apr 30 16:43:26 PDT 2012


That's because the minimum time to open is 8 hours by default so it is
adding like 7.9 hours to the times you are entering. You have to adjust it
down to 0 if you want to set the times like that.
-AZ


On Mon, Apr 30, 2012 at 7:06 PM, Matthew Jones <matthew at longsight.com>wrote:

> I was able to reproduce this on qa5-us, previously I was testing on a
> 1.3.x instance.
>
> The options to enable the options to appear are not default, maybe that's
> the source of some of the confusion?
>
> I had to click Administrate and Check
>
> * Use dates and times for evaluations, otherwise use dates only
> * Use stop date (grace period) for evaluations, otherwise just use the due
> date
> * Use view date for evaluations, otherwise just use the due date
>
> Then this evaluation is not possible to re-open or close.
>
> Also, I was entering the dates/times and the system still kept saving them
> as the wrong time. I'd put in like
>
> 04/30/2012 6:50 PM- Start
> 04/30/2012 6:55 PM- Due
> 04/30/2012 6:56 PM - Stop
>
> And it would put in times that didn't even *remotely* match the times I
> put in, bumping it to tomorrow at 3 AM (12 hours) even if I didn't want 12
> hours.
>
> So okay, I went back and put in times in 24 hour format. It gave a bunch
> of errors, though it still saved them even though times were "earlier" than
> the start time, though they weren't even matching anything I put in.
>
> I still couldn't reopen it though.
> http://screencast.com/t/1NulO9a0i6
>
> [image: Inline image 1]
>
> On Mon, Apr 30, 2012 at 6:33 PM, Aaron Zeckoski <azeckoski at unicon.net>wrote:
>
>> > There was a link to re-open it on the UI because it was past the stop
>> and due dates. But when I clicked on it, nothing happened, as it was still
>> waiting to hit the Viewable condition. There wasn't a link to close it
>> because it was already in the close state.
>>
>> That was what the bug was that was fixed (though in essence, the issue
>> there was that no eval could be reopened at all if that option was
>> enabled because of a missing check in the code added related to that
>> new option).
>>
>>
>> > So I guess that is kind of the undefined state? You're really reopening
>> a "Viewable" eval not a "Closed" eval? And you can't Close it if you're
>> between the Grace period and Viewable. I'd be happy to either be able to
>> close it (completely viewable and all) or re-open it. ;) For instance these
>> 2 I can't Re-open or Close. The Re-open link doesn't do anything and it
>> technically *is* closed. The workaround was to set the view date to *now*
>> so it can be re-opened.
>>
>> The states are inqueue -> active -> grace -> closed -> viewable so
>> something viewable is closed. It is after being closed so it can still
>> be considered closed for purposes where that check matters. In the
>> same way, the only state between grace period and viewable is closed
>> to you can't close an eval in that state because it is already closed.
>> That said, there could be some UI issue which is preventing the button
>> from appearing but I am not seeing that in my trunk code.
>> Reopening a viewable eval should work fine (and appears to on my test
>> server).
>>
>> -AZ
>>
>>
>> On Mon, Apr 30, 2012 at 6:17 PM, Matthew Jones <jonespm at gmail.com> wrote:
>> >
>> > Hmm, well on #1 I wasn't able to close the evaluation (EVALSYS-1135) or
>> reopen-it, though that sounds close.
>> >
>> > There was a link to re-open it on the UI because it was past the stop
>> and due dates. But when I clicked on it, nothing happened, as it was still
>> waiting to hit the Viewable condition. There wasn't a link to close it
>> because it was already in the close state.
>> >
>> > So I guess that is kind of the undefined state? You're really reopening
>> a "Viewable" eval not a "Closed" eval? And you can't Close it if you're
>> between the Grace period and Viewable. I'd be happy to either be able to
>> close it (completely viewable and all) or re-open it. ;) For instance these
>> 2 I can't Re-open or Close. The Re-open link doesn't do anything and it
>> technically *is* closed. The workaround was to set the view date to *now*
>> so it can be re-opened.
>> >
>> >
>> > As far as #2, I don't think I have enough stones to throw at RSF.
>> >
>> > On Mon, Apr 30, 2012 at 5:52 PM, Aaron Zeckoski <azeckoski at unicon.net>
>> wrote:
>> >>
>> >> Matt,
>> >> 1) That wouldn't be reopening a closed eval then. That would reopening
>> >> an open eval. But in this case, a viewable and closed eval are both
>> >> going to pass that check so that check would not stop the eval from
>> >> being able to be reopened. I think you might have the wrong cause for
>> >> your issue. There were other issues related to closed evals not being
>> >> able to be reopened in 1.4.
>> >>
>> >> https://jira.sakaiproject.org/browse/EVALSYS-1230
>> >> https://jira.sakaiproject.org/browse/EVALSYS-1135
>> >>
>> >>
>> >> 2) Null dates are translated when the eval object is loaded from the
>> >> database and converted into actual dates. That is the right way to
>> >> handle this and populating the database with dates which will not be
>> >> updated later if the option is turned back off could lead to some
>> >> pretty ugly bugs.
>> >> I think the real issue here is that something changed in the recent
>> >> version of RSF or perhaps the date picker or some code related to it
>> >> which means there are a few issues with dates and the way they are now
>> >> processing (most notably around the fact that RSF seems to load the
>> >> date data straight from the DB instead of using the values in the
>> >> object and that it also saves the values directly back to the DB at
>> >> the end of the request cycle even if the actual services were never
>> >> called. This only happens with the dates so and not with other data on
>> >> the page and I haven't had a chance to dig into it more but it seems
>> >> like the right fix here is to drop the RSF date picker and use the
>> >> jquery one which is being suggested for use by the rest of the Sakai
>> >> community (kill 2 birds with one stone).
>> >>
>> >> -AZ
>> >>
>> >>
>> >> On Mon, Apr 30, 2012 at 3:48 PM, Matthew Jones <matthew at longsight.com>
>> wrote:
>> >> > 1) We had an issue where an instructor couldn't re-open an
>> evaluation that
>> >> > was "apparently closed" come up. The problem was that it past the
>> "due and
>> >> > stop dates" but not yet viewable. (For another week, for whatever
>> reason)
>> >> >
>> >> > In the code it has:
>> >> >
>> >> >                 // check if already active, do nothing if not closed
>> >> >                 if (EvalUtils.checkStateAfter(currentEvalState,
>> >> > EvalConstants.EVALUATION_STATE_CLOSED, false)) {
>> >> >
>> >> > However the state order is      * States: Partial -> InQueue ->
>> Active ->
>> >> > GracePeriod -> Closed -> Viewable (-> Deleted)
>> >> >
>> >> > Does anyone else think that it should be "checkStateAfter
>> >> > EVALUATION_STATE_GRACEPERIOD ", which would catch the closed and
>> viewable
>> >> > states?
>> >> >
>> >> > 2) In the administration interface you can set the option
>> >> > " Use stop date (grace period) for evaluations, otherwise just use
>> the due
>> >> > date "
>> >> >
>> >> > If later you decide to remove this, all of the stop dates are "NULL"
>> in the
>> >> > database, and the UI looks kind of funky for displaying this field on
>> >> > previous evaluations.
>> >> >
>> >> > It seems like it this is enabled either two things should happen.
>> >> >
>> >> >   - The system should update the database and set all STOP_DATE
>> values that
>> >> > are NULL to be equal to the DUE_DATE.
>> >> >   - If the STOP_DATE is NULL and this option is selected, display the
>> >> > DUE_DATE instead (instead of an empty area, incorrect date)
>> >> >
>> >> > I didn't want to file these as issues in-case there was a reason for
>> them,
>> >> > but would be happy to write them up.
>> >> >
>> >> > _______________________________________________
>> >> > evaluation mailing list
>> >> > evaluation at collab.sakaiproject.org
>> >> > http://collab.sakaiproject.org/mailman/listinfo/evaluation
>> >> >
>> >> > TO UNSUBSCRIBE: send email to
>> evaluation-unsubscribe at collab.sakaiproject.org
>> >> > with a subject of "unsubscribe"
>> >>
>> >>
>> >>
>> >> --
>> >> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>> >> _______________________________________________
>> >> evaluation mailing list
>> >> evaluation at collab.sakaiproject.org
>> >> http://collab.sakaiproject.org/mailman/listinfo/evaluation
>> >>
>> >> TO UNSUBSCRIBE: send email to
>> evaluation-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>> >
>> >
>>
>>
>>
>> --
>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>
>
>


-- 
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/evaluation/attachments/20120430/5cefaacc/attachment.html 


More information about the evaluation mailing list