In some cases, axios errors might not have a response property. We should update our error handling to account for that case. axios has an example:

https://github.com/axios/axios#handling-errors

Among the dev dependencies that the vueify template introduced, there are several that now have a new major version. I think we should consider bumping these to the latest version after checking whether doing so would break anything.

• Add login page.
• When navigating to a route, check the session.
• Send session information with requests.

Right now if a request fails, we basically say, "Something went wrong." We should use the details that Jubilant sends back: either the Jubilant problem message or the problem code.

Right now Super Adventure uses eslint-plugin-html (this is how the Vue.js Browserify project template configured it), but it looks like there is an official ESLint plugin for Vue.js. The documentation for eslint-plugin-html says that the two are incompatible. Should we switch from eslint-plugin-html to eslint-plugin-vue?

The final JS bundle is 3.0MB, which is absolutely gargantuan. The bootstrap CSS is 112KB, which is more palatable but still seems highly excessive for a bunch of CSS. We should aim to bring these down by orders of magnitude by release.

Just wanted to check, do we have mock-ups that we could use for Jubilant?

I think in some cases, we cannot reuse a jQuery-managed element, but unless we use the right v-for key, Vue may try to do so.

As part of this, check the approach for the field key list.

IcoMoon generates a CSS file, as well as a JSON file that stores our icon selection and IcoMoon preferences. The two files do not include license or copyright information. We have not modified the JSON file, and other than changing paths, we have not modified the CSS file.

According to https://icomoon.io/app-features.html, the CSS file is MIT licensed. However, I found that page from Google, and it looks possibly outdated.

Based on the above, I have a few questions:

• Should we add license/copyright information about IcoMoon anywhere?
• If we do add license/copyright information, where is the best place to put it? At the top of the file? In our repository's NOTICE file? Both?
• If we do add license information, and if MIT is the correct license, should we add the entire MIT license or just mention that the file is MIT licensed?

Right now Super Adventure doesn't indicate to the end user that it is in the process of fetching data (for example, the list of forms or submissions). How about we add messaging for when that fetching takes a while?

Right now documentation links all navigate to the ODK documentation home. This issue is to make the links more specific.

I'm not sure we're removing all jQuery listeners and data as part of the Vue component destroy process. (Or at other times when we remove jQuery-managed elements, for example, removing elements in a data table before fetching fresh data.) One case: I think we might not be removing listeners and data from the popovers on the field key list page.

@clint-tseng suggests for UserResetPassword:

can we update that message to also indicate that the present password has been successfully revoked?

We want a router so that folks can go back in their browser history and so that they can add individual pages of Super Adventure to their bookmarks. Investigate the Vue.js router:

https://router.vuejs.org/en/

Right now Adventure doesn't monitor whether the session is expired.

Style tweaks to consider:

Navbar

• After clicking the user's email address and hovering over Log out, only part of the background is gray.
• Dropdown menus seem slightly misaligned with the edge of the buttons that open them (in navbar and other places).
• After collapsing the navbar and clicking the user's email address, the background color of Log out is gray.

Other

• In buttons, the icon could probably be a few more pixels away from the button text.

What should go in the dashboard?

Currently, when a user sets or resets their password, we do not restrict their password in any way. We also do not indicate the strength of their password.

At the least, we wish to indicate to the user the strength of their password. We're thinking we could use zxcvbn or a library like it to do so.

We may also wish to add password restrictions rather than just warnings, such that the user cannot choose a password that fails to satisfy certain restrictions. I think we would consider at least a restriction on password length ("the password must be at least X characters"). If we add such a restriction, we may need to update Backend as well.

As part of this, add tests of any table data that includes a date.

npm install warns:

npm WARN deprecated [email protected]: 🙌 Thanks for using Babel: we recommend using babel-preset-env now: please read babeljs.io/env to update!

The cheap solution since all our menus are short right now is just to pad out the bottom of tables.

If you have eg a lot of user accounts and reset a password way down the page, you never see the happy message because it's at the top of the page. I think this isn't a big deal for v1 but we should keep an eye on it.

It may be another catalyst to stop having many alert widgets all trying to do the same thing within pageflow and instead have them float above the entire page somewhere fixed.

I'm skipping these for now.

For example, Fetch API is broadly supported since last year: http://caniuse.com/#feat=fetch
(this would replace Axios)

For this issue, replace each loading message with a spinner throughout Frontend. Once that is done, remove the VisibilityDelay component. If as part of this, you have replaced <loading> with <spinner>, go ahead and remove the Loading component.

Ideally, the spinner used to replace the loading message will be larger than the spinner used in other places. However, it's also fine if it's the same size. Try applying a transform: scale(2.0) (use a Spinner prop to toggle this). However, if that breaks the spinner, don't worry about it — we can just have it be the same size.

The spinner used to replace the loading message should be centered. If the entire page or PageBody is blank, and only the spinner is shown, the spinner should be shown further down the page than the loading message currently is.

One tricky part of this is that some v-if directives may need to become v-show (or vice versa).

We need something like this as a more permanent solution for CORS.

Otherwise, I think the popover would end up positioned incorrectly? I think this is mentioned in the Bootstrap documentation.

We'll continue doing this once we decide on the app's name.

If the spinner is spinning for a long time, accidentally clicking on eg the grey background makes the whole dialog go away. This is scary!

@clint-tseng writes in #24:

i have been a happy moment user for many many years now, but they have a new one http://moment.github.io/luxon/ that seems cleaner, lighter, and better (immutable, for one). take a look?

• New form modal: next to "choose one".
• Submissions download button
• Form list: chevron next to form name.
• Field key list: QR code icon next to "See code".
  • Update toggleFieldKeyListPopovers() to account for icon.

Create/read/list/update users.

Right now the display name is just the email, so this isn't a big issue, but we should make the change at some point.

See the release criteria.

Two digits after the ~ is a good default in order to catch security updates. (But do a quick check of whether the package seems to be using semantic versioning.)

• Button should contain just a refresh icon. Once you click it, a spinner overlays the icon.
• Button should be in line with the table header.
• If the refresh fails, the page should show an alert.

Add license based on the conversation here.

Vue.js seems to have some testing tools. Can we utilize those?

As the user views the form and submission lists, we should automatically refresh the lists in the background.

We should think about messaging in case the list initially renders successfully, but then subsequent requests fail or take a long time.

1. Perform an action in a modal that triggers an error (eg reset password but the server isn't there).
2. Error appears at top of modal. Do not dismiss it.
3. Perform the action successfully.
4. Modal disappears and happy message is shown on the parent page.
5. Attempt to perform a new action with the same modal (eg resetting a different user's password).
6. Error is confusingly already present.

Blocked by #7.