Yea, I asked Hank if we should prevent people from being able to enter
these wrong in the first place. The issue is that there isn't much
feedback - just like how you were able to enter an invalid date and it
went un-detected.
I guess at some point, Hank will have to generate a master list of date
issues and we'll have to fix. If Marisa knows which other ones she did,
that would be helpful.
So there's kinda two issues:
1) the system should be better at preventing people from doing things
that aren't allowed
2) it's impossible for folks to remember all the details, but they
should at least remember one rule: if you aren't sure, ask. I think in
this case, Marisa noticed something she thought to be a problem and just
tried to fix it herself in a way she thought was correct. In most cases
this approach should be okay, but see issue #1
Paul
On 12/2/10 2:00 PM, Jeff Sharpe wrote:
> Hi,
> Marisa informed me she did about 75 of those last night. I will start on
> those tomorrow. She also said she has done many serials like that in the
> past with no problems.
>
> Thanks,
> Jeff
>
>> Yuck, a whole bunch more of Marisa's modify_xml tasks ran after we
>> started this discussion (they'd already been submitted, but were held up
>> by the catalog backlog until last night). We still have all these with
>> invalid dates:
>>
>> http://www.us.archive.org/metamgr.php?&srt=updated&ord=desc&w_date=*-*&w_identifier=classschedul*&fs_date=on&fs_identifier=on&fs_mediatype=on&fs_format=on&fs_collection=on&fs_curatestate=on&fs_noindex=on&off=0&lim=25
>>
>> And Jeff, when making changes like this, can you please use
>> modify_xml.php instead of editxml, so that the task history shows the
>> changes?
>>
>> --
>> You received this bug notification because you are a bug assignee.
>> https://bugs.launchpad.net/bugs/683953
>>
>> Title:
>> Invalid date information in items
>>
>> Status in Internet Archive - Tech Support:
>> Fix Released
>>
>> Bug description:
>> Three items from Provo --
>>
>> classschedule19291930brig
>> classschedule19301931brig
>> classschedule19311932brig
>>
>> had their date information changed from "1929" to a invalid date. This
>> caused the item to have no date associated with it at all in the search
>> engine.
>>
>> What to do:
>>
>> 1) Change the date to be valid (valid formats below)
>> 2) Confirm that this change has been made by replying to this bug report
>>
>> For reference:
>>
>> "...The valid formats for date are:
>> YYYY or YYYY-MM-DD or YYYY-MM-DD HH:MM:SS
>>
>> anything other than that in the date field (like YYYY-YYYY) is going to
>> cause problems - like no value entered at all in the search engine
>>
>> in fact, that ("no value entered at all in the search engine") is exactly
>> what has now happened with classschedule19301931brig. you can see here
>> that the search engine now has a blank value for "date" for that item,
>> because the value provided was in an invalid format:
>>
>> http://www.archive.org/advancedsearch.php?q=identifier%3Aclassschedule19301931brig&fl[]=date&fl[]=identifier&output=tables
>> ..." - Hank
>>
>> (assigning bug to Jeff Sharpe)
>>
>>
>>
>>
>>
Yea, I asked Hank if we should prevent people from being able to enter
these wrong in the first place. The issue is that there isn't much
feedback - just like how you were able to enter an invalid date and it
went un-detected.
I guess at some point, Hank will have to generate a master list of date
issues and we'll have to fix. If Marisa knows which other ones she did,
that would be helpful.
So there's kinda two issues:
1) the system should be better at preventing people from doing things
that aren't allowed
2) it's impossible for folks to remember all the details, but they
should at least remember one rule: if you aren't sure, ask. I think in
this case, Marisa noticed something she thought to be a problem and just
tried to fix it herself in a way she thought was correct. In most cases
this approach should be okay, but see issue #1
Paul
On 12/2/10 2:00 PM, Jeff Sharpe wrote: www.us. archive. org/metamgr. php?&srt= updated& ord=desc& w_date= *-*&w_identifie r=classschedul* &fs_date= on&fs_identifie r=on&fs_ mediatype= on&fs_format= on&fs_collectio n=on&fs_ curatestate= on&fs_noindex= on&off= 0&lim=25 /bugs.launchpad .net/bugs/ 683953 291930brig 301931brig 311932brig 301931brig. you can see here www.archive. org/advancedsea rch.php? q=identifier% 3Aclassschedule 19301931brig& fl[]=date& fl[]=identifier &output= tables
> Hi,
> Marisa informed me she did about 75 of those last night. I will start on
> those tomorrow. She also said she has done many serials like that in the
> past with no problems.
>
> Thanks,
> Jeff
>
>> Yuck, a whole bunch more of Marisa's modify_xml tasks ran after we
>> started this discussion (they'd already been submitted, but were held up
>> by the catalog backlog until last night). We still have all these with
>> invalid dates:
>>
>> http://
>>
>> And Jeff, when making changes like this, can you please use
>> modify_xml.php instead of editxml, so that the task history shows the
>> changes?
>>
>> --
>> You received this bug notification because you are a bug assignee.
>> https:/
>>
>> Title:
>> Invalid date information in items
>>
>> Status in Internet Archive - Tech Support:
>> Fix Released
>>
>> Bug description:
>> Three items from Provo --
>>
>> classschedule19
>> classschedule19
>> classschedule19
>>
>> had their date information changed from "1929" to a invalid date. This
>> caused the item to have no date associated with it at all in the search
>> engine.
>>
>> What to do:
>>
>> 1) Change the date to be valid (valid formats below)
>> 2) Confirm that this change has been made by replying to this bug report
>>
>> For reference:
>>
>> "...The valid formats for date are:
>> YYYY or YYYY-MM-DD or YYYY-MM-DD HH:MM:SS
>>
>> anything other than that in the date field (like YYYY-YYYY) is going to
>> cause problems - like no value entered at all in the search engine
>>
>> in fact, that ("no value entered at all in the search engine") is exactly
>> what has now happened with classschedule19
>> that the search engine now has a blank value for "date" for that item,
>> because the value provided was in an invalid format:
>>
>> http://
>> ..." - Hank
>>
>> (assigning bug to Jeff Sharpe)
>>
>>
>>
>>
>>