Hi Fiona,

I find recorder names to be one of several examples with Indicia where its flexibility and lack of proscription causes confusion. It is also made more confusing by the evolution over time. However, provided you know what you intend to store in the database, and your recorders understand the same, then you capture the information you want and can retrieve it.

One of my queries is why we store CMS user ID, CMS Username, CMS User First Name and CMS User Lastname and CMS User email in attributes when using the Easy Login module as the records are marked with the Indicia user id which keys in to the person table that stores first name, last name and email.

A possible reason is wanting to store values at the time of data entry as the person record might change. However, verifiers are only ever stored by their Indicia user id.

I also find the recorder names field in the sample table rather unappealing because it is one amorphous text field which you could write anything in.

I haven't got a good, tidy solution to offer for recording data-enterer, principal recorder and multiple subsidiary recorders.

Because we can all go creating custom attributes for rather fundamental things like recorder name there is a mechanism to drag all fields with similar meaning together to allow reporting across many websites. When you create a sample attribute you can assign it a system function including first name, last name, full name and email.

Just poking my nose in to the reports I see that they use the recorders field from the cache occurrences table. This field is populated by some queries that look in a whole bunch of different places to find a name. First choice is the samle.recorder_names field but if that is absent then it goes for first name + lastname. I expect you can observe that on your site, if there are no additional recorders, the data-enterer name is used.

John writes a comment in the code as follows:

You can find this in modules/cache_builder/config/cache_builder.php.

The order is
- Sample recorder names
- full recorder name
- surname, firstname
- Sample recorder names in parent sample
- full recorder name in parent sample
- firstname and surname in parent sample
- warehouse surname, first name
- CMS username
- CMS username in parent sample
- warehouse username

I suppose this helps a bit as it illuminates the thinking about the importance of different places for storing the names.

Jim Bacon.

Hi

Having thought a little more, here are some options for handling names, assuming the use of Easy Login, which should give expected results in the Explorer reports.

1. Where the data-enterer is the only recorder.
- No need to put a recorder field on the form as the data-enterer is always captured via the created_by_id of the record being set to the indicia_user_id.

2. Where there is one recorder who may be different to the data-enterer.
Either
- add a sample recorder_names control to the form
Or
- add sample attributes for first name and last name. This is helpful to ensure that a full name is supplied and not just a first name. It also helps with names where it is hard to distinguish first and last names. The attributes should be marked as having a system function of first name and last name.

- the data-enterer is captured via the created_by_id of the record.

3. Where there are multiple recorders.
- add a sample recorder_names control to the form. Some help text to encourage coherent input would be sensible.
- the data-enterer is captured via the created_by_id of the record.

Part of the verification process would be checking that a satisfactory name has been supplied.

Two ways to resolve your situation, Fiona, where you have recorder names in two places, are
- a custom report
- an update to the records so that the recorder names field includes the name in the first name and last name attributes.

Jim.