Inconsistent routes for editing records within "Urban Flora of Scotland" Activity

[kitenetter]

A number of difficulties have been reported by Julia Wilson at UKCEH who runs the "Urban Flora of Scotland" Activity on iRecord. The activity ID is 150.

I'm haven't been able to get a clear idea of what is happening, but for most records within this activity that can only be edited if you first go the Activity and choose "Explore activity data" - for these records you cannot edit them if you go via the normal "My records" route.

However, users report that there a proportion of records within the activity for which the opposite is true - they can only be edited via "My records", and not via the Activity "Explore activity data" button.

I think they would be happy if they could consistently use one route rather than the other, it is the inconsistency that is causing problems.

As far as I'm aware the only way to get records into this Activity is to enter them direct onto the website using the Activity's "Enter records" button, or to upload them from csv using the Activity's "Import records" button.

[kitenetter]

Initial investigation suggests that the difference in editing behaviour is related to whether the records are added via the website form or added via csv upload.

These record IDs were added by the website form, and can only be edited via the Activity "Explore activity data" button:

• 11980100
• 10541151

This record ID was uploaded from csv and can only be edited via "Explore - My records":

• 14197219

This also becomes confusing if the user views their record first and then tries to edit it. If you start from the Activity "Explore activity data" button and the choose to view a record, if you then use the "Edit this record" link from the record page you are unable to edit (because the link opens up the edit outside the Activity).

It's probably quite a big job to completely tidy up all the possible edit routes, but it would be helpful for users if were to be able to offer one consistent editing route that works for all records, whether added to the website or uploaded from csv.

[johnvanbreda]

Here's an explanation. When a record is added via the website, there is a field called samples.input_form which contains the path to the form used to enter the record (enter-bss-urban_flora in this case). When a record is added via CSV import, this field will not normally get filled in unless the user was aware and mapped it correctly.

When using Explore activity data, the edit link generated understands the activity the link is for. For records input via the website, it can generate a link to the correct activity input form and attach the correct group_id to the link. For records uploaded via CSV it doesn't know the input_form so links to edit-generic-record as a default, but this fails because the edit-generic-record form is not linked to the activity.

For the My Records route, it knows the input_form for records added via the website, so generates a link but does not add the group ID. As the enter-bss-urban_flora form is linked to the activity, this link fails (because the form expects a group ID in the URL). For records imported, the link is generated to edit-generic-record, but in this case these links work simply because the group_id is missing via this route.

As there are a few things going on here there are a few things we can do:

1. Quick fix - encourage activity members to set the Sample Input Form field to enter-bss-urban_flora for this activity's uploads as long as they are into the correct survey. The problem with this fix is it relies on users understanding what to do and doesn't fix the problem if encountered by other activities.
2. We could also correct existing data using the following SQL:

   select id into temporary to_fix from samples where survey_id=304 and group_id=150 and coalesce(input_form, '')<>'enter-bss-urban_flora'
   update cache_samples_functional set input_form='enter-bss-urban_flora' where id in (select id from to_fix);
   update samples set input_form='enter-bss-urban_flora' where id in (select id from to_fix);
   update cache_occurrences_functional set input_form='enter-bss-urban_flora' where sample_id in (select id from to_fix);

3. Allow activities to provide default values for data uploaded via their upload form. Then we can configure the Sample Input Form default value rather than expect everyone using the upload to understand how to do this. This is a medium sized task though, not trivial. It only fixes the issue for other activities if the activity admins understand how to set it up.
4. Change the edit generic record form to not complain if accessed with a group ID in the URL as long as you are editing a record which matches that group ID. Then both links on the Explore Activity Data will start working.
5. Change the enter-bss-urban_flora form (and other similar activity linked forms) to not complain if the link they are loaded from does not contain a group ID, as long as they are being used to edit a record in the activity they are linked to. That will make the links from My Records work.

I've run the SQL in 2) so data entered to date should be OK.

[johnvanbreda]

@kitenetter can you let me know if you want any of the other changes made?

[kitenetter]

@johnvanbreda thanks for the explanation and the updates in option 2.

I think the best additional option, short of making all links work in all cases, is your no. 5. It seems intuitive that users will expect to edit all their records from their "My records" view.

[kitenetter]

Just realised that we originally discussed this under #410.

Would like to implement option 5 when we can - adding to September milestone to review priority.

[kitenetter]

This issue has been raised again by the urban flora project, adding to July milestone.