Setting data for adopted probes

[Martin Kolárik]

• Rename probes but limited to the user's point of view. Not public. (dashboard only)
• User can change the probe city (and this updates the coordinates in the background). Must be a valid city in the detected country.
• Tag system. Allow the user to set a limited amount of tags on adopted probes. Then he would be able to use the API to query them specifically. Something like tag:u-jimaek-value . Example use case: A company wants to use Globalping to run tests from their own specific locations and avoid all public probes. They would add them to the network and adopt them. They would then be shared by all of course. But they can also tag them to allow them to run their own tests only from their probes. e.g. a CDN running a probe in every POP to test their latency to the internet

[Alex Yarmosh]

A few questions:

• are all user tags publicly visible to everyone?
• algorithm of creating u-jimaek-value tag. As I understand user only inputs the value part, and u-jimaek- is autogenerated. To get the jimaek value:
  • dashboard BE does a gh api request by gh id during the creation of a new adoption, and stores login in the adopted probe item;
  • since gh login may change we also need a cron that will sync gh logins by gh ids.
• validating the city. I see the algorithm as:
  • user edits the adopted probe and fulfils 2 inputs: country and city;
  • dashboard BE does a geonames request with the country and city values and saves the city, country and coordinates of the best result in the adopted probe item;
  • GP API only uses city from the adoption if country from adoption === country from geoip search.

geonames has is 10000 credits daily limit per application, the hourly limit is 1000 credits. 1 search requires 1 credit.

@MartinKolarik @jimaek does that look ok?

[Dmitriy Akulov]

A few questions:

• are all user tags publicly visible to everyone?

Yes

• algorithm of creating u-jimaek-value tag. As I understand user only inputs the value part, and u-jimaek- is autogenerated. To get the jimaek value:

  • dashboard BE does a gh api request by gh id during the creation of a new adoption, and stores login in the adopted probe item;

We get the username during registration, no need to make new requests during adoption. Just take the value from our DB.

• since gh login may change we also need a cron that will sync gh logins by gh ids.

I dont think we need a cron, we can auto-update usernames on every login into the dashboard

• validating the city. I see the algorithm as:

  • user edits the adopted probe and fulfils 2 inputs: country and city;

We already have these 2 fields filled with system data. Why do we need to make the country editable at all?

• dashboard BE does a geonames request with the country and city values and saves the city, country and coordinates of the best result in the adopted probe item;
• GP API only uses city from the adoption if country from adoption === country from geoip search.

geonames has is 10000 credits daily limit per application, the hourly limit is 1000 credits. 1 search requires 1 credit.

@MartinKolarik @jimaek does that look ok?

[Martin Kolárik]

I dont think we need a cron, we can auto-update usernames on every login into the dashboard

Or have a button to do it manually or ignore the case completely for now.

validating the city. I see the algorithm as:
user edits the adopted probe and fulfils 2 inputs: country and city;
We already have these 2 fields filled with system data. Why do we need to make the country editable at all?

We agreed that the user can change the city but not the country. So show the country as we detected it but don't allow changing it. I suppose we need to do #428 first so that the dashboard has the existing values.

[Alex Yarmosh]

I'll skip the update of username for now. And country is required to do the valid geonames search, using readonly country from GP is fine.

[Dmitriy Akulov]

Let's do username updates on login. Should be simple and better than nothing or manual actions

[Martin Kolárik]

Is it better? If the tags change and you use them in a script, it breaks. Manual action seems better.

[Dmitriy Akulov]

If we do manual we might as well allow the user to free edit the field. But I don't see the problem, usernames change rarely and it's obvious that you're relying on some random guy. He could delete his tags or enter trash data at any point.
This way we keep things simple and it feels more polished

[Martin Kolárik]

Disregard 3rd party tags. I meant my own. If I happen to change my username, it will not be immediately clear to me if/when the tags change. "On the next login to the dashboard" is rather arbitrary; we can detect it during the login and show a message + ask for confirmation, but it should not happen in the background. And since as you said, it's a rare thing, I would be ok with leaving this out entirely for now.

[Dmitriy Akulov]

I guess it's up to you to either do it now or later, but I still think it must be automated on login at the very least. If you want to add an extra cron it's fine but it just sounds like another component that could break.

Let's just not forget about this functionality, maybe open a new issue?