Setting data for adopted probes

[MartinKolarik]

Setting data for adopted probes

[alexey-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?

[jimaek]

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?

[MartinKolarik]

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.

[alexey-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.

[jimaek]

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

[MartinKolarik]

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

[jimaek]

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

[MartinKolarik]

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.

[jimaek]

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?