Unable to enter transect walk data

[DavidRoy]

@andrewvanbreda - are there post-migration issues with this site?

Problems reported by user = https://pollinator-monitoring.net/user/99

Page fails to load: https://[pollinator-monitoring.net/walk-data-entry?location_type_id=777&date=12/04/2023](https://pollinator-monitoring.net/walk-data-entry?location_type_id=777&date=12/04/2023)

Report of problems: I already set up the three sites we have in Wallonia, Belgium. This part went well. Now I'm trying to set up the transects. I'm blocked because on the "Transect setup" screen, the "Site for transect" is empty and I cannot fill that in. Without that information I cannot move forward, nor add data to them. How can this be fixed? I face the same problem to enter the data from the pantraps.

[andrewvanbreda]

@DavidRoy OK I will look now.

[andrewvanbreda]

Hi @BirenRathod, Do you know how to fix this one? I am seeing this message "was blocked due to MIME type (“application/json”) mismatch (X-Content-Type-Options: nosniff)." On the report call poms/get_squares_for_country_id

I have put the site in maintenance mode.

[BirenRathod]

Hi Andy This could be due to settings introduced in the warehouse using the Apache web server. I have to ask our IT team to look into this.

[andrewvanbreda]

@BirenRathod @DavidRoy OK thanks for checking this. I have left the site in maintenance mode for now. If the site needs to be live for other areas of the site, feel free to take out of maintenance mode as you see appropriate, but those pages will be broken until resolved. I am 80% sure this wasn't broken on original testing for Drupal 10 and is a new thing.

[BirenRathod]

@andrewvanbreda Can you send me the page URL, please?

[andrewvanbreda]

@BirenRathod I know of 2 that do it

https://pollinator-monitoring.net/walk-data-entry?location_type_id=777&date=01/01/2023

https://pollinator-monitoring.net/enter-pan-trap-results-fixed-square-survey

[BirenRathod]

thanks, @andrewvanbreda . so I can track down the error & page.

[BirenRathod]

@andrewvanbreda Can you try again accessing that page after clearing a cache from the browser? see if you can spot that error.

[andrewvanbreda]

@BirenRathod It still occurs, have emailed you the exact message as has auth tokens in so won't post it here

[BirenRathod]

@andrewvanbreda I found this -> is the report available?

[andrewvanbreda]

@BirenRathod It is in Github, I assume it hasn't been deleted off the warehouse? https://github.com/BiologicalRecordsCentre/indicia-reports/blob/master/reports/projects/PoMS/get_squares_for_country_id.xml

The report hasn't changed for a year.

I assume that path in your message is not case sensitive

[BirenRathod]

@andrewvanbreda It has been case-sensitive since moving to the new infrastructure.

[andrewvanbreda]

@BirenRathod I see. OK, I will see the best way to correct this situation and get back to you.

[BirenRathod]

@andrewvanbreda check if this affecting other reports on POMS or SPRING. I'm checking on the server too.

[andrewvanbreda]

@DavidRoy @BirenRathod The "PoMS" project appears to be unique in that it is the only project with capital letters in its project name in indicia-reports. For consistency the most obvious fix to this would be to change this to lower case. However that makes me nervous as it could break the apps if those are using correctly-cased paths.

I suggest we leave the project name, and I will search the code and change it to say PoMS. Also I look for this on individual page configurations.

The problem is if we do it the other way, and change the project name to be lower case, we might have many more changes to do (even if the naming convention would be more consistent).

@DavidRoy Do we need to get Karolis to double check app code?

[andrewvanbreda]

@DavidRoy @BirenRathod Just getting some reports of this issue on NPMS. So will have to check all my projects. I think projects with acronym names are most at risk in this kind of variation.

[DavidRoy]

@kazlauskis can you check that any fit count reports used by the app are lower case. That’s the only app link to PoMs

[andrewvanbreda]

@DavidRoy @kazlauskis As we aren't changing the project name, the poms paths should says "PoMS" in mixed case.

Althernatively if you prefer we can change the project name to "poms" in indicia-reports, however I don't have rights to change that if you are wanting to do it that way.

[andrewvanbreda]

@DavidRoy I have taken SPRING out of maintenance mode as the original reported issues are now fixed for that site.

I will continue to check the pages on that site and the code/pages for my other projects.

[BirenRathod]

@andrewvanbreda do you want to make changes to the folder path to lowercase or it is not required?

[andrewvanbreda]

@BirenRathod Leave that, because if we change the folder name it will break current paths which have been entered correctly.I think will cause more problems that it is worth because currently most paths do have the correct case so we would break all those. Thanks for checking though. (if Karolis comes back to us with a different view on the matter then we can revisit the idea of changing the project folder name).

[BirenRathod]

@BirenRathod Leave that because if we change the folder name it will break current paths which have been entered correctly.I think will cause more problems that it is worth because currently most paths do have the correct case so we would break all those. Thanks for checking though. (if Karolis comes back to us with a different view on the matter then we can revisit the idea of changing the project folder name).

@andrewvanbreda I'm fine with that setting. I don't want to break those sites too. In the future, we could use lowercase for all reports for consistency point of view. Also, would be a good idea to get the list reports using that folder path.

[andrewvanbreda]

@DavidRoy @BirenRathod So far I have checked SPRING/UKPoMS/NPMS I do not think this problem is widespread. I corrected 4 occurrences of incorrect paths in SPRING PHP code, no problems in page configuration. UKPoMS has no problems. NPMS only 1 problem in the configuration of an admin page. I will give my other sites a check, but I do not expect any issues beyond isolated incidents.

I think the main risk is probably in the apps, just depending on how Karolis wrote the paths. They also may be higher risk as they are harder to patch if needed as I understand it.

[andrewvanbreda]

@BirenRathod @DavidRoy I checked my other sites. FIT Count/Plant Portal/EBMS/UKBMS

The only problem I found was 2 problems in the file ukbms_site_details.php for the UKBMS site. In that case the report path had been entered with the pathname using an uppercase "U" in ukbms. In that particular case I wasn't the programmer, so I cannot be certain your other projects with other programmers wouldn't have a similar issue to what I did with case inaccuracies in report paths.....even if it isn't common. I guess we should wait for Karolis feedback before closing this issue.

[BirenRathod]

@andrewvanbreda Once again thanks for checking this. @kazlauskis please check the app.

[kazlauskis]

@andrewvanbreda The FIT count app uses warehouse1.indicia.org.uk/index.php/services/rest/reports/projects/PoMS/get_projects_for_country.xml report to fetch the projects list. It is currently working OK as it is, do you think I should change it somehow?

Does this affect other apps, like the ButterflyCount?

[BirenRathod]

@kazlauskis just make sure that the path of the folder same as it is in the reports of GitHub repository. The reason is on the new server all files & folder paths are case-sensitive, so should be identified by the report used in the apps & websites.

[andrewvanbreda]

Hi @kazlauskis That report example is indeed correct.

As Biren said, the requirement is simply that all paths to reports are now exactly case senstive, so in theory this could affect any report path. It really depends on how exact you have been case-wise with your report paths. You might have no problems at all.

In my checks almost everything has been ok website-wise, just a few problems.

[andrewvanbreda]

John has john contacted me about this as he saw errors relating to this in the Warehouse logs. However they are the same problems that were fixed yesterday, this does suggest that most of the other paths are likely ok else we would be seeing them in the logs.

[andrewvanbreda]

Closing this. I just double-checked this is still working. Resolved.