Not a major issue.

Seems to be because page number 1 starts, but max page is 0, or something along those lines

[
  {
    "ele": "abc",
    "createdAt": 1573675693644,
    "updatedAt": 1573675693644,
    "id": "5dcc62ad019645e3f38356b9",
    "uuid": "5313d3b1-6e86-40c1-bba3-d5a28a5ea89e",
    "lat": 1,
    "lon": 2,
    "elev": 0,
    "url": "ltsyrealjones.com"
  }
]

This is data that has persisted across web server restarts in spite of having a field ele that is not even in the Model (Record.js). This was found while testing validation and is related to #2. Many other fields are present in the db storage as well that are autogenerated (createAt, updatedAt, id) however, I did not expect that incorrect fields like ele would make it all the way to the db and persist...

• Perhaps looser constraints are on the db in dev mode?

There are advantages to the current method of doing this:

• Download copy of records from server and cache. Paginate from this copy.

However, handling server side will be better in the long run, if we can avoid some pitfalls like someone else adding Records strangely displacing current slice of Records.

Right now, footer is a decent placeholder. Probably have less GH buttons, and introduce some catchall buttons: def: the most usual use cases for the website (in case someone gets to the bottom but doesn't see what they want)

In reference to homepage.ejs

Don't deal with registration of new users, just have a conix/conix user

• Investigate possible Sails resources for this
• Investigate usual ways to test websites
  • dm/ih might know this already
  • google-fu
• using curl in a shell script would be technically feasible

The correct way of doing these checks:

https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests

var xhr = new XMLHttpRequest();
xhr.open("GET", "/bar/foo.txt", true);
xhr.onload = function (e) {
if (xhr.readyState === 4) {
if (xhr.status === 200) {
console.log(xhr.responseText);
} else {
console.error(xhr.statusText);
}
}
};
xhr.onerror = function (e) {
console.error(xhr.statusText);
};
xhr.send(null);

Consider disabling input to field as well! (maybe with re-generate button?)

Navbar waits to extend until it is very large, which leaves huge unused margin by the time that it does expand.

• Might be based on a larger viewport than needed for full navbar expansion...

Forms like ATLAS/atlas-web-app/views/pages/create-record-form.ejs may need to be revisited periodically to ensure that their user input is being sanitized/validated properly.

Sails has a lot of nice built-in server-side validation features, see:

https://sailsjs.com/documentation/concepts/models-and-orm/validations

Other bits in root README.md are good, move these to this repo's wiki pages

ATLAS now functions such that ARENA Scenes are geometric points and the ARENA user has a search radius, effectively making them a geometric circle. Basically, this logically needs to be reversed: ARENA Scenes having a 2D area and users being points. The user search query would then be: "What ARENA Scenes am already intersecting?" versus previously: "What ARENA Scenes are within n km of me?"

^ Decent paraphrase, @anthonyrowe ?

For ARENA Direct Entry page

Include certain scenes as static options, but allow write-in for new scenes or "unlisted" scenes

Currently testing algorithm is:

1. Nav to atlas/create-record-form
2. Submit form without any input

• Expect HTML pop-up prompting for input in UUID

3. Go back
4. Fill out all fields with 'abc'
5. Submit form

• Expect failure due to malformed UUID

6. Go back
7. Input valid UUID
8. Submit form

• Expect failure due to malformed URL

9. [repeat for each field]

Adding a record_group attribute to the Record model can simplify geo queries, and also other logical operations on logical groupings.