Skip to content

Count usage of client print#9446

Open
BacLuc wants to merge 2 commits intoecamp:develfrom
BacLuc:count_usage_client_print
Open

Count usage of client print#9446
BacLuc wants to merge 2 commits intoecamp:develfrom
BacLuc:count_usage_client_print

Conversation

@BacLuc
Copy link
Copy Markdown
Contributor

@BacLuc BacLuc commented Apr 11, 2026

See individual commit messages.

BacLuc added 2 commits April 12, 2026 00:01
Can be removed again once we do not want to measure this anymore.
I just needed a place to log a request,
and logging it similarly to the nuxt pdf request made sense.
It makes also sense to then analyze the logs from the same container.

Add .nuxtrc to .gitignore as nuxt generates this, most probably when
the @nuxt/test-utils are used.
With a request to the print service.
@BacLuc BacLuc requested a review from a team April 11, 2026 22:26
@BacLuc
Copy link
Copy Markdown
Contributor Author

BacLuc commented Apr 11, 2026

Our terms of service already include:

We collect your personal data directly from you or in connection with the use of the website (e.g. IP address, MAC address of the smartphone or computer, information about your device and settings, cookies, date and time of the visit, pages and content accessed, functions used, referring websites).

https://www.ecamp3.ch/en/tos/#collection-of-data

Which kind of includes this too.

* Endpoint to log usage of clientPrint
*/

export default defineEventHandler(async (event) => {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this in the print service? If people try to print large camps with nuxt, then nuxt crashes, then they try with client print, this will not be logged. Could we use sentry or betteruptime or collect logs from elsewhere?

Copy link
Copy Markdown
Member

@carlobeltrame carlobeltrame Apr 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also interesting could be success / failure ratio and time taken to print, and maybe the camp id and print config, for further debugging. Just the raw usage count doesn't say much yet imo, and it's biased because of habits and nuxt print being labeled "number one".

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2eedc21

Can be removed again once we do not want to measure this anymore.
I just needed a place to log a request,
and logging it similarly to the nuxt pdf request made sense.
It makes also sense to then analyze the logs from the same container.

Add .nuxtrc to .gitignore as nuxt generates this, most probably when
the @nuxt/test-utils are used.

I didn't want to use sentry because then we would use an american company again where we also can do this without other data krakens.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@carlobeltrame :
success/failure, userId (evtl hashed)

-> we start here, if i have time i can move the endpoint

)
})

it('logs the print config when passed', async () => {
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

printconfig is logged here

@BacLuc
Copy link
Copy Markdown
Contributor Author

BacLuc commented Apr 12, 2026

if you prefer i can try to log the success/error and the time taken.
I just wanted it as less intrusive as possible. But it shouldn't matter if we put the request in the event queue right after the rendering or after the rendering was successful.
Maybe the latter is even better...?

@BacLuc BacLuc requested review from a team and carlobeltrame April 12, 2026 09:27
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.

2 participants