Minor problems discovered in v4.4

[grumpyinca]

1. The typo "indepoendent" appears in 6 places.

2. The context-specific Help associated with the "No Free Independent Variables" Search/Seek error needs to be improved to better serve users that do not yet fully grasp Fix/Free and Independent Variables.

3. It appears the #785 is not working as intended. URL's with the form /?nnnn= continue to appear as "bounces" in Google Analytics. See Client Id: 1933475394.1681838647 & 666774752.1681838656 10:24am PST Apr 18, 2023.

4. Change line 30 of logUsage.js from: displayMessage('POST of usage_log of note \''+note+'\' failed with message: \''+error.message+'\''); to: displayMessage('POST of usage_log of note \''+JSON.stringify(note)+'\' failed with message: \''+error.message+'\'');

5. See comment on getDBSize added below 4/29/2023.

6. See comment on network-related failures reported in usage-log added below on 5/6/2023.

[1fifoto]

Item 1. Done, 6 changes made.

Item 2. I'll leave that one to you to complete.

Item 3. Minor: I can't easily see Google Analytics entries, would it be possible to capture them (screen shot?) and paste them under item 3 above.

Item 3. I went to "https://odop.herokuapp.com/?1234=" and got a status response of 500. There is not much else I can do.

Item 4: The change is just a way of seeing the "[Object]", but it does nothing to repair the actual underlying problem.

[grumpyinca]

In the process of adding the requested detail to item 3 above, I observed that the Page Title is shown as "(not set)". This could be significant. I looked back in history and found these two examples of page titles:

SpringDesignSoftware.org Dec 18, 2022 Client Id 1309031346.1671421866 Page title Free Coil Spring Design Software and Calculator | ODOP:Spring Page URL /

odop.herokuapp.com Dec 18, 2022 Client Id 1282479813.1671417494 Page title Open Design Optimization Platform Page URL /?4356=

Separately, I created a custom report from Analytics that shows the broad variety of URLs encountered in a single day (April 18, 2023). Issues785and835_Analytics.pdf Note lines 15 and 16.

While none of this is absolute proof, it has led me to speculate that the changes in v4.4, (branch #785) are actually working as designed and are effective in preventing the undesired requests that come into odop.herokuapp.com from appearing in the bounce category of Google Analytics. I continue the speculation to say the example in item 3 above is coming to some "/" URL that is not odop.herokuapp.com. Exactly what URL that is, I can't say.

In summary, I would say that we should not invest additional effort in pursuing item 3 above.

[grumpyinca]

Today's Analytics activity has produced a counterexample to my speculation in the previous comment:

also:

[grumpyinca]

Regarding the reply to Item 3 above ... I checked the Analytics log for entries from Austin around 5pm on the 19th. I didn't find any. I checked the usageLog for entries around that time. I didn't find any.

Separately, I was not able to find a usageLog entry associated with the Analytics entry (Client Id=1891207870.1682091322) in the previous comment.

When I follow the link: https://odop.herokuapp.com/?1234=, No entry appears in the usageLog.

[grumpyinca]

Regarding item 3 in the original issue write-up ... There may be other ways to deal with unwanted activity from specific geographic areas. See the free databases and web services provided by IP2Location.com:

• database
• web service

[grumpyinca]

Entries created by production users containing "getDBSize" like: "2017, 2023-04-28 02:17:59, 2023-04-28 02:17:59, 13.212.24.80, {"tag":"event","action":"HelpAbout","note":{"event_value":18,"event_label":"getDBSize"}}" appear in both Analytics reports and the usage_log.

A test against the production system Help : About produced a usage_log record of: 2261, 2023-05-01 03:25:47, 2023-05-01 03:25:47, 172.125.76.185, {"tag":"event","action":"HelpAbout","note":{"event_value":4,"event_label":"getDBSize"}} but did not display any database size information.

I conclude that the getDBSize entry is just a distraction ... an artifact associated with logging but not visible to production users. Aside from a desire to eliminate the distraction in the future, there is no need for action.

[grumpyinca]

A (returning?) Linux-based user from Boardman, OR seems to have encountered multiple network-related failures. Is there anything to be learned by examining the usage log ? See Google Analytics from 10:52am PDT today. Google Client Id 1919175122.1683395490.

[grumpyinca]

Browsing the usage_logs for development and staging systems, I observe that the message: {"tag":"event","action":"DisplayMessage","note":{"event_value":13,"event_label":"message: POST of usage_log of note '[object Object]' failed with message: 'Failed to fetch', variant: danger"}} seems to be same-second associated with: {"tag":"event","action":"BeforeUnload","note":{"event_value":12,"event_label":""}}

Perhaps this is a clue to the origin of the message and also the reason why the user does not see the pop-up message.

[grumpyinca]

Re: 2. in initial description above:

• Added See also: links in /docs/Help/alerts.md
• Polished wording in errors.md for improved readability

Pushed the changes into the branch.

[1fifoto]

Merged into master, closing