Ah yes, I can see how that this is irritating. The reason it does this is to do with re-determinations. When you're re-determining something, the defaults as they are currently being presented are very often quite appropriate. However, when you're adding a new occurrence altogether, I can see how it would be much more sensible for it to default to the recorder and date given in the sample.

Hopefully Lynn will note this issue and put it forward as a CCN.

Sorry, I thought any change is considered a CCN? I just meant hopefully it will be noted and fixed. :)

Just to clarify the situation:

When a new occurrence is added, the determiner will be blank and the date will come from the sample.

When a new determination is added, the determiner will be the currently logged-in user and the date will be "today's" date.

Is that correct?

I see, thanks for the clarification. One would have thought I would know these things by now. ;)

Mark

I would agree that in most cases the recorder/observer will be the determiner and would support a default of this rather than it being left blank.

Steve

The determiner defaulting to the user currently logged on and the date defaulting to today’s date was Part 5 of CCN241 - Review of verification procedure, so it was a requested/paid for change in version 6.13. However, the CCN doesn't make it very clear exactly when it should happen. It just says 'When adding a new determination ...' which has been interpreted as new to the system not as a second or subsequent determination to an existing taxon occurrence. As CCN248 introduced the use of F11 to populate date fields with today's date and name field's with the name of the person logged on I would argue that F11 should be used when required and that these fields should auto-populate to more helpful values, although F11 doesn't work in the Find Recorder Name box after clicking the Add (+) button to add a recorder to a survey event, for example. I think determiner should default to the first recorder on the sample and the date should default to the date of the sample.

Hi - can I say that it appears that the date still defaults to todays date when entering a taxon occurence manually into an event.  (v 6.13.3)  as I have just discovered this one on upgrading.any chance on it being recitifed to defaulting to the event date.  And the det. type defaults to unconfirmed -no tsure why, surely original would be better? or blank?

Louise Bacon
CPBRC

HI Lynn,

these are all records from a county recorder.  The switch to unconfirmed also occurs when records in an excel spreadsheet are imported.  therefore, either there needs to be an option to import this column in the import wizard (there may be - it has  never been an issue before) or this needs to be something which one can chose to assign, rather than the task I now have of going through each sample one by one, editing and changing this manually.

All records importedprior to our move to 6.13 have the determiner type of observation, OK not necessairly correct in all circumstances but better than unconfirmed.

If the determination types are all the same for all the records in a single import to be done via one run of the wizard (as in the case mentioned by Louise) it should be possible to save a filter of the records just imported at the end of the import process and then use that in a xml batch update to change the determination type for the records just imported. You would then need to run another xml batch update to bring the Verified flag on the taxon occurrence into line with the determination type on the preferred determination - Mike Weideli has already written this one. The problem is that last time I looked at the filters you could save after importing data they weren't working properly - they were returning more records than were actually imported. Lynn, will this be fixed in the next release? When it is fixed this procedure should tied us over until the determination type becomes a column you can import via the wizard although it really needs to be added to the standard data entry windows.