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

Mon Apr 30 15:33:55 PDT 2012

> 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