Notify user that conflicting duplicates exist and allow for deletion
Description
Activity
Jon Gorrono
done.
Peter Peterson
Just to be clear...this is a "Will not fix" and should be closed, correct? I reviewed this and the logic seems sound, so I suggest Jon closes the issue.
Jon Gorrono
This query was designed to identify the problematic items: all names that are duplicated disregarding case in the
highest version of objects of the same time with in the same category
and with in the same gradebook
select
lower(name),
count(lower(name)),
gradebook_id,
category_id,
object_type_id,version,removed
from gb_gradable_object_t
group by
gradebook_id,
category_id,
object_type_id,
lower(name),
version,
removed
having count(lower(name))>1
and removed = 0 and version = max(version)
This returns 29 results from our ~135k active items (that statistic could include inactive sites, however)... most are from testing sites. One is a Tests & Quizes entry that has the same timestamp on both.
I think it's fair to say we do not have a pervasive problem in this regard thus far and just continue to close the avenues for the dup's within gb2 (in other tickets)
Jon Gorrono
As it turns out, I cannot find any way that an external assessment tool could create duplicates based on different cases... the external assessment service in edu-services hinges on the following test for existence:
protected Assignment getAssignmentWithoutStats(String gradebookUid, String assignmentName, Session session) throws HibernateException {
return (Assignment)session.createQuery(
"from Assignment as asn where lower(asn.name)=lower and asn.gradebook.uid=? and asn.removed=false").
setString(0, assignmentName).
setString(1, gradebookUid).
uniqueResult();
}
and so would find collisions without case sensitivity
So the only way that we could get this problem is if some tool that is not using the external assessment service creates the condition: gradebook2 and gradebook (1) are the only ones I know that could do it... so this may not be worth fixing...
Comments?
items from other tools can differ by text case only and be considered different (GBRK-1204), and they are considered duplicates in GB2 if in the same category.When duplicates like this exist, and since updates to these items are passed through business rules that throw exceptions because the items appear to be duplicates, this process prevents a 'delete' update.
1) Remove businessrule checks during item deletes (none of them really seem to apply)
2) add 'dup name' businessrule checks during getRoster (if not already there)
3) notify user of exceptions from #2 and advise them to remove items that duplicate in order to remove the notification