Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[TASK-1059] Handle submission groups in Access Log UI #5115

Conversation

magicznyleszek
Copy link
Member

@magicznyleszek magicznyleszek commented Sep 18, 2024

Checklist

  1. If you've added code that should be tested, add tests
  2. If you've changed APIs, update (or create!) the documentation
  3. Ensure the tests pass
  4. Make sure that your code lints and that you've followed our coding style
  5. Write a title and, if necessary, a description of your work suitable for publishing in our release notes
  6. Mention any related issues in this repository (as #ISSUE) and in other repositories (as kobotoolbox/other#ISSUE)
  7. Open an issue in the docs if there are UI/UX changes

Description

Describe the outcome of your work here. A non-programmer who is familiar with KoboToolbox should be able to understand what you've written; more technical details can be added to the Notes section below. You may omit this if the title alone provides enough information. Both the title and this description will be published in the release notes on our forum.

Notes

Describe what you've changed and why. This should allow the reviewer to understand more easily the scope of the PR. It's good to be thorough here.

Related issues

Build atop #5094 (TASK-869-group-submissions-better) and #5109 (task857-access-log-ui)

p2edwards and others added 30 commits July 15, 2024 14:15
…instead of canceling if another one failed
Here's the error we were encountering when running mocha-chrome
on Node >=17:

```
Promise Rejection:  Error: connect ECONNREFUSED ::1:39193
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1606:16) {
  errno: -111,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '::1',
  port: 39193
}
```

Here's the patch that fixes this for us:

   // node_modules/mocha-chrome/lib/client.js
-  const client = await CDP({ port: instance.port });
+  const client = await CDP({ port: instance.port, host: '127.0.0.1' });

An alternative patch that would also succeed:

   // node_modules/chrome-remote-interface/lib/defaults.js
-  module.exports.HOST = 'localhost';
+  module.exports.HOST = '127.0.0.1';

Another option:

   // node_modules/chrome-remote-interface/lib/external-request.js
-  const {address} = await util.promisify(dns.lookup)(options.host);
+  const {address} = await util.promisify(dns.lookup)(
+    options.host,
+    {family:'IPv4'},
+  );

Thank you @nsainaney for writing this comment in nodejs/node#40702 [^1]:

> It appears to be a breaking change with how DNS.lookup works. With
> node 16, the lookup would return a IPv4 address but with node 17, it
> returns an IPv6 address which will break most REST clients that
> hardcode URLS like http://localhost:4040/api if the upstream server
> only binds to the IPv4 address (e.g. server.listen('127.0.0.1'…) etc…

[^1]: nodejs/node#40702 (comment)

Before committing to the 'patch' strategy, I checked to see if either
mocha-chrome or chrome-remote-interface had been updated later with this
workaround.

- chrome-remote-interface accepts a parameter for host, so nope.
  Makes sense, since you can specify the host manually.
- mocha-chrome doesn't parameterize host, and the author of mocha-chrome
  considers it an obsolete package and is no longer updating it.
…gation is more consistent/secure

also adds some useful comments
# Conflicts:
#	jsapp/js/projects/projectsTable/projectQuickActions.tsx
#	jsapp/scss/libs/react-tagsinput.scss
…into kobocat-django-app-part-2-remove-service-account
# Conflicts:
#	jsapp/js/account/security/email/emailSection.component.tsx
#	jsapp/scss/libs/react-tagsinput.scss
…emove-imports

Code refactoring - Replace shadow models imports with their openrosa app counterparts
fix thumbnail resizing with FileSystemStorage
Fix 500 error when submitting data after changing the password
…t-uniqueness

(backport) Fix 500 error when submitting data after changing the password
pauloamorimbr and others added 26 commits September 11, 2024 14:26
…rmdisclaimer

Fix bad performance introduced in `2.024.25`
…ject-button-text

[ TASK-1027 ] Conditional label for 'Delete Project and Data' button
…hments-tests

Skip temporarily some failing tests
…e the same consistent DRY CSS module as other security sections
Copy link

@magicznyleszek magicznyleszek deleted the task1059-access-log-ui-submission-group branch September 18, 2024 16:30
@magicznyleszek
Copy link
Member Author

Closed in favor of #5116

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants