[BUG] The Kubeconfig from Support -> Download Kubeconfig, for use with Terraform eventually goes bad / stops working, spitting back unauthorized

Describe the bug
Given a download kubeconfig (check docker shell):
root@jenkins-staging:/home/ubuntu/mike-workspace/harvester-baremetal-ansible-new-airgap-provisioning-instance/jenkins# docker ps
CONTAINER ID   IMAGE                                          COMMAND                  CREATED         STATUS         PORTS                                              NAMES
f6eae734eb05   mikeairgap-jenkins:mikeairgap-jenkins-latest   "/sbin/tini -- /usr/…"   3 minutes ago   Up 3 minutes   <IP_ADDRESS>:8072->8080/tcp, <IP_ADDRESS>:50002->50000/tcp   mikeairgap-jenkins-ansible
14d5a9bd1d54   mike-jenkins:mike-jenkins-latest               "/sbin/tini -- /usr/…"   7 days ago      Up 7 days      <IP_ADDRESS>:8071->8080/tcp, <IP_ADDRESS>:50001->50000/tcp   mike-jenkins-ansible
root@jenkins-staging:/home/ubuntu/mike-workspace/harvester-baremetal-ansible-new-airgap-provisioning-instance/jenkins# exit
exit
ubuntu@jenkins-staging:~/mike-workspace/harvester-baremetal-ansible-new-airgap-provisioning-instance/jenkins$ docker exec -it mikeairgap-jenkins-ansible /bin/bash
f6eae734eb05:/$ cat /var/jenkins_home/workspace/harvester-airgap-integrations
harvester-airgap-integrations/     harvester-airgap-integrations@tmp/
f6eae734eb05:/$ cat /var/jenkins_home/workspace/harvester-airgap-integrations/
.git/          .gitignore     README.md      ansible/       jenkins/       swagger/       terraform/     terraform@tmp/
f6eae734eb05:/$ cat /var/jenkins_home/workspace/harvester-airgap-integrations/terraform/integration-cluster-kubeconfig.yaml
apiVersion: v1
kind: Config
clusters:
  - name: "local"
    cluster:
      server: "https://a.b.c.d/k8s/clusters/local"
      certificate-authority-data:
        "STUFF"

users:
  - name: "local"
    user:
      token: "kubeconfig-user-xgs5h7bvlp:mcq9r7crnzq9t6t85ttcd2gcxg6jgr8gbf9f9s8wwr6nrl2xgsvpnl"

contexts:
  - name: "local"
    context:
      user: "local"
      cluster: "local"

current-context: "local"

f6eae734eb05:/$

It eventually "expires" it seems.
When utilizing Terraform w/ elements like:
# STUFF
BUILD_DISPLAY_NAME=#1

JENKINS_VERSION=2.440.3

JENKINS_INCREMENTALS_REPO_MIRROR=https://repo.jenkins-ci.org/incrementals

HUDSON_HOME=/var/jenkins_home

TF_VAR_k3s_rancher_key=terraform-k3s-rancher.tfstate

JOB_BASE_NAME=harvester-airgap-integrations

PATH=/opt/java/openjdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

KUBECONFIG=/var/jenkins_home/workspace/harvester-airgap-integrations/terraform/integration-cluster-kubeconfig.yaml

bucket=airgap-integrations-provisioning

force_destroy_k3s_rancher=false

BUILD_ID=1
# MORE STUFF

And:
terraform {
  required_providers {
    harvester = {
      source  = "harvester/harvester"
      version = "0.6.4"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "2.16.0"
    }
    ansible = {
      version = "1.2.0"
      source  = "ansible/ansible"
    }

  }

  # Current Work-Around Needed: https://github.com/FlexibleEngineCloud/terraform-provider-flexibleengine/issues/1074#issuecomment-1827861856
  backend "s3" {
    encrypt                     = false
    skip_requesting_account_id  = true
    skip_s3_checksum            = true
    skip_region_validation      = true
    skip_credentials_validation = true
    skip_metadata_api_check     = true
    use_path_style              = true
    insecure                    = true
  }
}

# resource "ansible_vault" "secrets" {
#   vault_file          = "vault.yml"
#   vault_password_file = "/path/to/file"
# }

locals {
  module_path                = abspath(path.module)
  terraform_script_root_path = abspath("${path.module}/..")
  codebase_root_path         = abspath("${path.module}/../..")

  # Trim local.codebase_root_path and one additional slash from local.module_path
  module_rel_path = substr(local.module_path, length(local.terraform_script_root_path) + 1, length(local.module_path))
}

provider "harvester" {
  # Configuration options
  #kubeconfig = abspath("${local.codebase_root_path}/integration-cluster-kubeconfig.yaml")
}

provider "kubernetes" {
  #config_path = abspath("${local.codebase_root_path}/integration-cluster-kubeconfig.yaml")
}

And:
sh 'echo "" && env && echo "" && TF_LOG_PROVIDER=DEBUG TF_LOG=TRACE ./terraform plan'

To Reproduce
Steps to reproduce the behavior:

Have a Harvester Cluster of N nodes
Download the Kubeconfig
Utilize it for 2/3+ weeks
Try to utilize it for your pipelines / automation / etc.:
it stops working
implement workaround

Workaround:
On one of the Harvester nodes:
harvester-sxtvs:/home/rancher # cat /etc/rancher/rke2/rke2.yaml

Replace server ipv4, w/ VIP IP.
Use that...instead of the Support -> Download Kubeconfig
Expected behavior
Support -> Download Kubeconfig to not expire / go stale
Environment

Harvester ISO version: v1.3.0
Underlying Infrastructure: bare-metal

Additional context
I kept hitting, errors like:
╷
│ Error: Unauthorized
│
│   with provider["registry.terraform.io/harvester/harvester"],
│   on provider.tf line 47, in provider "harvester":
│   47: provider "harvester" {
│
╵

So I started thinking to myself, "why is this happening, it didn't used to happen, what took place?" - I attempted to make pivots and changes that took the shape and form of:

commenting out the kubeconfig portion in both the Harvester & Kubernetes provider in the provider.tf for each microservice, thus introducing a env.KUBECONFIG variable in the Jenkins pipeline to see if that resolved things
"hardcode" the kubeconfig path in the provider.tf, as to not leverage dynamic local & abspath Terraform functionality
provide each nested terraform microservice it's own terraform binary x86_64 to leverage

none of that ^ worked.
But once implementing the workaround, things are absolutely fine.

Is this perhaps the same issue as:
https://github.com/rancher/rancher/issues/44912
https://github.com/harvester/harvester/issues/5827

@m-ildefons  - hmmm it very well might be.
There was a Rancher cluster wired up, through vCluster, though not really leveraged much.
Yet this was a cluster on v1.3.0.
It was first created on the 19th of March, 2024.
The issue was noticed on April 23rd, 20204.
So the issue was picked up at around 35~ days.
But!
Very well could have been present at 30 days.
The embedded Rancher uses v2.8.2:
containerStatuses": [

    {
        "containerID": "containerd://2572dfa4542311c4cfa8c5571bcd45ebaebc80b9fdf17e84722a8500d087c06b",
        "image": "docker.io/rancher/rancher:v2.8.2",
        "imageID": "sha256:547f93d5b621b6e396f48ffd9338ada5eb99ec5f0a77480decda34ca133f229c",
        "lastState": { },
        "name": "rancher",
        "ready": true,
        "restartCount": 0,
        "started": true,
        "state": {
            "running": {
                "startedAt": "2024-03-19T19:15:37Z"
            }
        }
    }

]

@m-ildefons - thanks for pointing this out, built up repro steps and a customized docker ntp server to handle ease of faking the date so that it's easily reproducible
Will close in favor of:
https://github.com/harvester/harvester/issues/5874
As https://github.com/harvester/harvester/issues/5874 is more detailed :smile:
Thanks for that mention!


Markdown scroll position jumps while editing and preview is shown

VSCode Version: Code 1.12.0 (72672be0b7d3eef0784077b880615f91b7ec85aa, 2017-05-04T16:10:14.237Z)
OS Version: Darwin x64 15.6.0
Extensions: none

Steps to Reproduce:

Open smoke test's readme.md
Open preview side-by-side
Start editing the .md half-way down
Sometimes the scroll position jumps

+1 @ 1.12.2, 19222cdc, Windows 10
I'm finding it jumps as soon as I type a single character. It's like fighting a spring.

There have been a few fixes in this area so I believe this may have been fixed. @chrmarti let me know if you see this in the latest insiders


Fix WindowsEventLog: Evaluation of event log differ - Fixes #229

Pull Request (PR) description
Fixing issue #229 and reduce the Get-EventLog evaluation.

This Pull Request (PR) fixes the following issues
- Fixes #229

This change is

Codecov Report

Merging #262 into dev will decrease coverage by <1%.
The diff coverage is 100%.

@@         Coverage Diff         @@
##            dev   #262   +/-   ##
===================================
- Coverage    87%    87%   -1%
===================================
  Files        12     12
  Lines      1404   1402    -2
===================================
- Hits       1235   1233    -2
  Misses      169    169

@Outek - are you still working on this one?

Sorry, i make a new PR.


fix: unique key warning

There might be a better way to solve this but this seems to remove the warning about not returning a list with unique keys.

Thanks for that, I you could indeed use a Fragment instead of a div here. Doing so we will have the same markup but without the error.
You can import it line 7  with useState, useEffect, useCallback.

Perfect, thanks!


401 error

I've set the shop password secret, and I've checked it works via the browser, but I'm getting a 401.
Configuring shopify CLI
Will run Lighthouse CI on https://***
==============================
Creating development theme
✗ Please login again with shopify login
==============================
Configuring Lighthouse CI
Fetching product handle
There's been an error when querying the API

curl: (22) The requested URL returned error: 401

This is with an as yet unmodified Dawn theme. Any ideas?

I've tried your solution (added both test products and collections) and nothing still. Same message as yours.
Here's my lighthouserc.js file content which is se to repo root:
module.exports = {     ci: {       upload: {         target: 'temporary-public-storage',       },     },   };
As well as my ci.yml snippet:
name: Shopify Lighthouse CI on: [push] jobs:   lhci:     name: Lighthouse     runs-on: self-hosted     steps:       - uses: actions/checkout@v2       - name: Lighthouse         uses<EMAIL_ADDRESS>       with:           app_id: ${{ secrets.SHOP_APP_ID }}           app_password: ${{ secrets.SHOP_APP_PASSWORD }}           store: ${{ secrets.SHOP_STORE }}           password: ${{ secrets.SHOP_PASSWORD }}           lhci_github_app_token: ${{ secrets.LHCI_GITHUB_TOKEN }}   theme-check:     name: Theme Check     runs-on: self-hosted     steps:       - uses: actions/checkout@v2       - name: Theme Check         uses: shopify/theme-check-action@v1         with:           token: ${{ github.token }}
Any ideas what I'm doing wrong?

Ugh. The docs haven't made it to shopify.dev yet and we haven't updated the dawn repo.
If you look at the README you should see that authentication is done with Custom Apps now. Assuming you are working on a fork of Dawn, try the new authentication method.
It should be this:
name: Shopify Lighthouse CI
on: [push]
jobs:
  lhci:
    name: Lighthouse
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v2
      - name: Lighthouse
        uses<EMAIL_ADDRESS>        with:
          access_token: ${{ secrets.SHOP_ACCESS_TOKEN }}
          store: ${{ secrets.SHOP_STORE }}
          password: ${{ secrets.SHOP_PASSWORD }}
          lhci_github_app_token: ${{ secrets.LHCI_GITHUB_TOKEN }}
  theme-check:
    name: Theme Check
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v2
      - name: Theme Check
        uses: shopify/theme-check-action@v1
        with:
          token: ${{ github.token }}


Request: one-sided shadows

Bug, feature request, or proposal:
Proposal
What is the current behavior?
Currently, angular-material supports elevation levels through elevation-z classes, which adds shadow around the element. However, sometimes it's useful to have shadow only one one-side of an element.
What is the use-case or motivation for changing an existing behavior?
It helps in cases where we want to create components that encapsulates logic rather than presentation. For example, we currently have a component that renders both a <nav mat-tab-nav-bar> and the tabs underneath it, so that we only need to have the logic for computing these tabs in one component and it only needs to compute once. We also want the <nav> element to have shadow at the bottom, but not on the top, because the <nav> should belong visually with other UI elements. This is currently not possible with the elevation-z classes in Angular Material.

Closing since I don't think we'll do this at this stage


Implement pushTransaction for the transaction received handler

To allow Stoa to build its transaction pool it needs to know when transactions are added to the pool.
This allows it to set the incoming address by adding 'transaction_received_handler_addresses' to the setting.
Received a transaction push only valid a transaction.
Related to #1403

CI failure is unrelated.


add new faculty: technology

added new faculty alongside the departments. In tech and probably unibadan as a whole, each department uses specialized codes for course titles. I wasn't sure if this would be appropiate for your use case as acronyms.
For example, in Faculty of Tech

department
course code prefix

Mech. Engr
TME

Petr. Engr
TPE

Civi Engr
TCE

hi @plutack! thanks for contributing! 🚀
I think the acronyms you mentioned in your comment are good to go so long as it is recognized by students on campus.

I updated the acronyms for the ones i know


Availability in non-German App Stores

I was excited to download the app this morning, thanks for the great work in getting it ready!
However, I notice that it is only downloadable from the German App Store. For a very large number of people living in Germany their phones are signed into a different nation’s App Store and this current approach could limit uptake.
Is it possible to make the app available in other app stores?

I don't think this is possible unless Apple specifically allows them to release the App in other App Stores, too. As far as I know Apple and Google said they'll only allow one app per Country App Store (with possible exceptions).

I don't think this is possible unless Apple specifically allows them to release the App in other App Stores, too. As far as I know Apple and Google said they'll only allow one app per Country App Store (with possible exceptions).

I’m aware of that statement but I don’t know how it translates into availability of national apps in different app stores. Perhaps one of the devs can comment, or someone that knows about app releases for Apple?

Dear colleagues,
we will clarify this issue with the Robert Koch Institute. They are the official entity that released the app in the respective app stores.
We will keep you updated as soon as we know more.
Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team

Agreed. If you have any subscriptions active it's impossible to switch between AppStore countries. I use the UK Store and can't change this. It will prevent asking all visitors to Germany (especially from higher current incidence countries, e.g. UK) to download and use the app.

I can confirm that switching between Apple accounts from different countries is a huge pain. I'm still locked to my UK account, but would like to use the German tracker app while in Germany. It's hard to believe Apple would block the apps in other app stores - please keep us posted on what the RKI says.

Italian and Swiss Apps based on the same framework are available in other countries for some weeks now, hence shouldn’t be an issue with Apple and Google.
The reality is, that people have Apple IDs/Google Accounts based on their first signup and never change, e.g. for above reasons and many others. People live in different countries throughout their lives and move around. For longer or shorter periods of time. Also: people live and work in different countries around border areas.

I don't think this is possible unless Apple specifically allows them to release the App in other App Stores, too. As far as I know Apple and Google said they'll only allow one app per Country App Store (with possible exceptions).

I assume this policy means that only one developer in a country has the ability to request the Exposure Entitlement from Apple but it doesn't prevent you to release the app in multiple stores.

I don't think this is possible unless Apple specifically allows them to release the App in other App Stores, too. As far as I know Apple and Google said they'll only allow one app per Country App Store (with possible exceptions).

I assume this policy means that only one developer in a country has the ability to request the Exposure Entitlement from Apple but it doesn't prevent you to release the app in multiple stores.

Agreed. It seems a shame that what looks like a good, conscientious, open-source based project has been failed by management decisions. Surely use cases explored would include tourists visiting Germany and people travelling across borders for work / leisure etc.
Just offering the app in the German stores seems like an incredibly blinkered decision.

Yeah this is certainly a limitation that could hamper adoption, particularly in the more international or touristy cities. At the moment when travelers arrive in Germany, they are asked for contact details and contact tracers follow up shortly after to check in and see if they have developed any symptoms. I can imagine that they may want to invite travelers to install this app instead which would simplify things.
I’m in a similar situation (along with a number of my colleagues), live in Germany but stuck on another App Store.

I don't think this is possible unless Apple specifically allows them to release the App in other App Stores, too. As far as I know Apple and Google said they'll only allow one app per Country App Store (with possible exceptions).

I assume this policy means that only one developer in a country has the ability to request the Exposure Entitlement from Apple but it doesn't prevent you to release the app in multiple stores.

Hopefully! I fully agree that it doesn't make sense for the app to only be available to Users of the German App Store, it should be available for everyone visiting/living in Germany, regardless of App Store used.

While it’s possible to have apps installed from multiple accounts on one device (Log out and back in in to country B in Settings, install app, log out and back in to country A) - it requires multiple email addresses, and a technical understanding of how App Store accounts work that may be too high a bar for a casual user. Would love for all users to have easy, unhindered access to this in all app stores where possible, especially given the high quality English localization that  has been built.

Indeed. It’s bad enough an EU-wide app wasn’t developed, it would be a shame to shoot adoption in the foot by making it impossible (or setting the bar too high) for a portion of the population and visitors to install.

While it’s possible to have apps installed from multiple accounts on one device (Log out and back in in to country B in Settings, install app, log out and back in to country A) - it requires multiple email addresses, and a technical understanding of how App Store accounts work that may be too high a bar for a casual user. Would love for all users to have easy, unhindered access to this in all app stores where possible, especially given the high quality English localization that has been built.

This is impossible if you have subscriptions on iOS, e.g. Apple Music. You have to cancel all subscriptions first, then switch stores. I doubt anyone will be willing to do this.

While it’s possible to have apps installed from multiple accounts on one device (Log out and back in in to country B in Settings, install app, log out and back in to country A) - it requires multiple email addresses

that's how I'm using the local apps in Germany, as my primary AppStore/iTunes account is from my country "of origin". For updates you have to do the same. But everything else is working.
And my subscriptions are from my primary country. Never changed. It's working.

I've come across this problem with other apps too and it's frustrating to see this happening here too. Mostly the people that upload an app to the App Store are unaware of what consequences it has to restrict an app to a specific region. If you never moved to a different country, you don't know how frustrating this whole process is.
It's anyway not a 100% restriction, anybody can create a new iTunes account and circumvent that. But even if you do that, as soon as you switch accounts Apple Music resets all your downloaded music 🙄
So please just make it available fo all regions.

This is impossible if you have subscriptions on iOS, e.g. Apple Music. You have to cancel all subscriptions first, then switch stores. I doubt anyone will be willing to do this.

It’s impossible to change stores associated with your account, but it is possible to change the app store to use a different app store account. Onerous, but possible.

Indeed...the multiple accounts workaround is possible (that's what I'm using).
I think that before we pile on the devs too much, we should wait on @SebastianWolf-SAP to get more information from RKI as he promised. Never associate to malice what could be explained by simply overlooking something...I'm very appreciative that they at least engage with us :)

Indeed...the multiple accounts workaround is possible (that's what I'm using).
I think that before we pile on the devs too much, we should wait on @SebastianWolf-SAP to get more information from RKI as he promised. Never associate to malice what could be explained by simply overlooking something...I'm very appreciative that they at least engage with us :)

Absolutely, not attacking the devs themselves, its a management snafu if anything :)

I can confirm that I installed the Italian 'Immuni' App from the US App Store to test the functionality. So the one app per country rule is not enforced in this way. Please adjust.

Also the Latvian app is available in the German app store and can even live side by side with the German app. https://www.apturicovid.lv/

I am in a similar situation, however im on the Brazilian Apple Store. I can’t download it without leaving my family group/all my subscriptions.

I don't think this is possible unless Apple specifically allows them to release the App in other App Stores, too. As far as I know Apple and Google said they'll only allow one app per Country App Store (with possible exceptions).

What they said is that only one "Entitlement Profile" is available per country:
https://developer.apple.com/contact/request/download/Exposure_Notification_Addendum.pdf
Ie, only one entity per country is allowed to produce a contact-tracing app which uses the Exposure Notification APIs.
That has nothing to do with the distribution of the app though.
This isn't only about residents of Germany using different countries' App Stores, but also visitors. Surely Germany actively wants visitors to use its app when on the German federal territory? I don't think coronavirus checks whether you are a resident of the country you're currently in. :)

100% agree! I moved from Switzerland to Germany a couple of years ago, still work in Switzerland, and my iOS is still locked to the Swiss AppStore.
I tried to switch the AppStore in the past, but it needed a German credit card, which I don't have.

I’d love to be a responsible permanent resident and install this app, but I really have no interest in potentially losing access to my bank accounts back in the US by switching over to the German App Store when, things being how they are, I’m unlikely to be able to make a short visit home anytime soon.
Is there a way to compile it ourselves and install it using XCode, or will only the officially-signed version in the App Store work properly?

@amandadebler I suspect only the officially-signed version will work properly, but hopefully the people up the food chain at the RKI will see sense and release it worldwide :)

I’d love to be a responsible permanent resident and install this app, but I really have no interest in potentially losing access to my bank accounts back in the US by switching over to the German App Store when, things being how they are, I’m unlikely to be able to make a short visit home anytime soon.

It's easy. Just register a 2nd itunes/appstore/apple account with a different email (you can for example use a gmail alias if that is your primary email) and it could be also an account without BANKING information (if you don't have any in Germany!). You can download the free apps with that. As mentioned earlier just logout with Account A, login with Account B, download the app, and log back with Account A.  I have 3 Apple logins, for 3 country I'm interested in. One is my primary. With all my subscriptions, etc. But there are 2 others, also with paid apps and free apps. One has a credit card information, one doesn't have any payment information (only for free apps, not available in my region!).

@alneven Multiple Accounts is not a solution and also not a good workaround.
Also for most people creating multiple accounts is a huge hassle, exactly what you don’t want for an app that you already have to convince people to use and where the usefulness of the app depends on as many people as possible using it.

Multiple Accounts is not a solution and also not a good workaround. Logging out of your account messes up a bunch of things (Like deleting all your offline music from Apple Music) and other things.

the Logout is only from the AppStore application, not under Settings (!)
it's like to switch accounts in Twitter or Instagram
the main Apple ID/Icloud/Itunes account is not changed
but I understand your concerns, the app should be available in every appstore (if it's even possible?)
because who should decide in which one it should be presented, there are so many nations in Germany ;-)

About 13% of people living in Germany are foreigners (source).
It's difficult enough to get people to use this app. I think everything should be done to remove this barrier.
If I understand correctly, this is due to Apple's restrictions. Nevertheless, the message should be relayed that this is a matter of life and death.

About 13% of people living in Germany are foreigners (source).
It's difficult enough to get people to use this app. I think everything should be done to remove this barrier.
If I understand correctly, this is due to Apple's restrictions. Nevertheless, the message should be relayed that this is a matter of life and death.

It's not an Apple restriction. See @holtwick above (https://github.com/corona-warn-app/cwa-app-ios/issues/623#issuecomment-644716432) - Apple only permit one authority per country, not one app per store country.

About 13% of people living in Germany are foreigners (source).
It's difficult enough to get people to use this app. I think everything should be done to remove this barrier.
If I understand correctly, this is due to Apple's restrictions. Nevertheless, the message should be relayed that this is a matter of life and death.

 As far as I know, those have nothing to do with the Entitlement to use the ExposureNotification Framework, that should be completely separate. If RKI decides to check the checkboxes for availability in other countries, no review is required and it should go live there within the hour.

About 13% of people living in Germany are foreigners (source).
It's difficult enough to get people to use this app. I think everything should be done to remove this barrier.
If I understand correctly, this is due to Apple's restrictions. Nevertheless, the message should be relayed that this is a matter of life and death.

It's already taken care of, we just have to wait now: #623 (comment)

Is it actually taken care of though?
As @Gernot has said, it's a bunch of checkboxes in App Store Connect. In fact, it's probably easier to publish in every App Store globally than to publish only in one country - you have to go out of your way to do that.
Given the seriousness of this, it's a little hard to understand why RKI couldn't already have made a decision yesterday to fix this. What is even the debate?

Given the seriousness of this, it's a little hard to understand why RKI couldn't already have made a decision yesterday to fix this. What is even the debate?

Agreed. I'd hoped they'd have sorted this out by now as my view is its a pretty bad decision if it was deliberate.

The bigger concern at this point is that the big PR push about the app is nearly over. When the app finally /is/ available to be downloaded by people on other app stores, how will everyone know to try again?  This actually makes the topic quite urgent: the longer it takes, the more it hurts adoption, which directly challenges the goals of the project.

Dear colleagues,
we will clarify this issue with the Robert Koch Institute. They are the official entity that released the app in the respective app stores.
We will keep you updated as soon as we know more.
Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team

Glad to hear you're already working on this issue. I agree with @bmulholland that this is an urgent matter. Let's hope it gets resolved quickly!

This problem about the app being only available on the german app store whether it is IOS or Android should be resolved quickly. When I hear the statement 'The best corona app in the world!' I've to LOL because only those on the german app store can download it. Clearly the politicians have dismissed to ask for an app that is available worldwide which would have made more sense. We're EU, Schengen, Open-Borders. No, we're still in the middle-age and Corona has shown this very clearly.
I've also the problem with the app being only available in the German store. I'm a luxembourgisch person living in Germany.

Can not support this issue more.
Using my Russian apple account for almost 10 years and have to stick to that as it is also major account for my family group.
Apple policy about local stores limitations with not possibility to side load local apps (like in this corona warn app case) just drives me crazy every time... !!!!

Something I've been puzzled by, is that why it matters which app you install since the app doesn't use location and therefore any application, as long as you can read it, should be able to use the API and provide the required information since all it does is track proximity to other Bluetooth devices and all of this is handled by the phone software developed at a global level.
I understand why each country is restricted to one app because you have to name the health service of that country in order to be responsible for testing and making sure the testing is compatible with the technology on the phone.
But since the tech works in a global fashion across all phones, then shouldn't all countries have identical testing methods and use the same TAN/QR system for verification, etc, etc.
Then why does it matter what country I'm in? Does anybody know why?

Could we get an update on this issue @SebastianWolf-SAP? If it is really taking weeks to solve it, then I would go for the workaround and open a German account.
However, this is an important issue and should be solved asap!

This shouldn’t be a question. This is a legitimate issue for all of us non German residence. I want to install the app to protect my kids and I and I cannot. Retail as an priority issue and not a question. Please take this seriously as I and many others are at risk because of bad planning and to be told it is a question and not a legitimate issues is a bit condescending.

As this isn’t an issue with the app code itself and the maintainers of this repo don’t appear to have direct control over this issue, perhaps we should also communicate with the App’s own Technical Hotline at +49<PHONE_NUMBER>

I think that’s the telekom hotline with 1-day trained call agent working bees - I guess no one with technical expertise. I am Sure your complains are forwarded to /dev/null

I tried the hotline before I thought of checking here. Indeed the problem was either not understood by the person talking to me or simply ignored. I expect the first. Using a German App Store account is just not possible for many of us.
I think the developers working on the application might have the best chances to get heard. I am surprised we don't hear more in the media about this large group of people being locked out of participating with the app -- as a result of an obviously conscious decision of the RKI.

Maybe it was fixed in the meantime?! Check the comment from Adel

Can't find it in the Austrian store, I only see Corona Warn Apps from a lot of other countries.

for anyone who want to track whether it was fixed (it's for checking if the app is available in Play Store, but I guess it will be fixed at the same time as availability in App Store):

open incognito tab (in case you are logged in with Google account right now)
go to https://play.google.com/store/apps/details?id=de.rki.coronawarnapp&gl=DE
change last two letters of above link to another country
(e.g. https://play.google.com/store/apps/details?id=de.rki.coronawarnapp&gl=FR)
if install button disappears then it means that app is not available in this country

@alneven where i can find the source of the screenshot?

for anyone who want to track whether it was fixed or where the app is available right now (it's for checking if the app is available in Play Store, but I guess it will be fixed at the same time as availability in App Store):
* open incognito tab (in case you are logged in with Google account right now)

* go to https://play.google.com/store/apps/details?id=de.rki.coronawarnapp&gl=DE

* change last two letters of above link to another country
  (e.g. https://play.google.com/store/apps/details?id=de.rki.coronawarnapp&gl=FR)

* if install button disappears then it means that app is not available in this country

Correct, you can also check the availability of the app in the AppStore via a similar principle:

German AppStore: https://apps.apple.com/de/app/corona-warn-app/id1512595757
Austrian AppStore: https://apps.apple.com/at/app/corona-warn-app/id1512595757
UK AppStore: https://apps.apple.com/gb/app/corona-warn-app/id1512595757

Right now the app is not yet available in other countries AppStores (as far as I checked).
Not sure if it works on an Apple OS as well, just tried it on Windows.
But for prove of concept of the above methode works for the App NINA:

German AppStore: https://apps.apple.com/de/app/nina/id949360949
Austrian AppStore: https://apps.apple.com/at/app/nina/id949360949
UK AppStore: https://apps.apple.com/gb/app/nina/id949360949

for anyone who want to track whether it was fixed or where the app is available right now (it's for checking if the app is available in Play Store, but I guess it will be fixed at the same time as availability in App Store):

open incognito tab (in case you are logged in with Google account right now)
go to https://play.google.com/store/apps/details?id=de.rki.coronawarnapp&gl=DE
change last two letters of above link to another country
(e.g. https://play.google.com/store/apps/details?id=de.rki.coronawarnapp&gl=FR)
if install button disappears then it means that app is not available in this country

Still not on Apple US. Apple seems slower with the roll out.

@sonicalchemy It's not an Apple Problem. It's Robert Koch Institute problem, they have to click some buttons.

@SebastianWolf-SAP Are there any updates, or any sense of timeline? What considerations are holding this up? Given it really is a matter of health, should we be considering workarounds that cost us money in canceled app store subscriptions?
Sadly I think the PR window has passed. Are there any ideas on the team on how to improve adoption in the expat community, who now have the perception that they simply cannot use the app?

@bmulholland For Americans associated with the Army and Air Force, there's AFN (Armed Forces Network) radio and TV, along with various post-wide email lists. Also, English-speaking churches, which tend to have very international congregations.
But don’t bother with any of those until the app is in the US App Store, findable under “corona app Germany” and similar, because if I’m hesitant to try the account-switching trick, there’s no way in heck 99% of that crowd will even consider it.

Does it seriously take more than a week for the RKI to tick a checkbox?
What is the downside of making the app available without a region lock? This issue should have been solved 7 days ago.

This is a bit embarrassing for the RKI now, especially as we've an outbreak in NRW mainly involving foreign factory workers.

I wish there was someone at RKI that we could contact directly; it seems that no one is monitoring this issue at all.

@ileitch @bmulholland Other than pinging the RKI publicly on Twitter and the like, perhaps trying to make Drosten & Co (“Corona Update” from NDR) aware of this gap?

but I really have no interest in potentially losing access to my bank accounts back in the US by switching over to the German App Store [...]

True. But also, why are your US banks restricting their apps to the US AppStore?

@SebastianWolf-SAP Can you ask someone from RKI to comment directly in this thread?
The open way in which Corona-Warn-App has been developed is rather spoiled by the addition of this 'middleman' that seems to be playing by rather different rules.

Which middleman would that be, @kennethmac2000? SAP (who @SebastianWolf-SAP works for) is the sub-contracted development house, but RKI remains the contracting party and as such the responsible party for publishing the app to the app stores. Sure, there are internal processes to be followed here, and I suspect that RKI may not necessarily want to have to process data for non-residents (other than those who have travelled inside Germany and who may have exposed or been exposed to infected people). There are legal issues at play.
However, I do agree with others that the German app should be available in other country app stores for precisely the reason that people will start travelling and that incidental contacts will be helpful for tracking potential infection crossovers. I've contacted the RKI and requested that their PR team start poking their internal folks to get the app published on other app stores for that reason.

I think it was a good idea to ask RKI on twitter about this. One by one. Everyone. ;-)

I have already tagged RKI in this on Twitter. This is really insensitive to not have done this parallel in the development phase.

Have done so - twice. No response, no acknowledgement, no fix. I honestly don't think anyone on the RKI side is actually monitoring their twitter feed. Seems to be more of an announcement account rather than an interactive one. However, since there hasn't been any update so far, I have the strong feeling that they deliberately don't want to put the app in other app stores, for whatever reason that might be :-(

What’s the expression about not attributing to malice what can more reasonably be attributed otherwise. Let’s get their email and send requests to that instead?

I would say lack of planning a fore thought. Not thinking who the app is for ultimately.

Paired with failing to understand what country restrictions in App-Stores actually mean and how they have no real meaning except for marketing reasons.

I suspect that RKI may not necessarily want to have to process data for non-residents

While having an Apple ID that is linked to the German App Store is a useful proxy for German residence, it hardly guarantees it. Therefore, RKI are no doubt already processing data for non-residents. And what's the big deal?

other than those who have travelled inside Germany and who may have exposed or been exposed to infected people

If they are going to process data for certain types of non-resident, what is the problem with processing data for any type of non-resident?

No clue what might be the issue with RKI - Federal Government has no problem to publish many apps in foreign App Stores (this is for Android but same applies to iOS):

No clue what might be the issue with RKI - Federal Government has no problem to publish many apps in foreign App Stores (this is for Android but same applies to iOS):

you forgot the Ausweis app for NFC reading of the ID card. (AusweisApp2)

Dear colleagues,
finally we have an official statement from the Robert Koch-Institute which is also reflected in our FAQ: https://www.coronawarn.app/en/faq/#international and https://www.coronawarn.app/de/faq/#international

After a detailed examination of the situation it was determined that for legal reasons any publication of the Corona-Warn-App in App Stores outside of Germany is currently only possible after a case-by-case assessment. Legal consultations have shown that in the case of publication in international App Stores, the law of the respective country must be considered and applied to the Corona-Warn-App. This applies in particular to data protection, any necessary claims for information by local authorities and other contractual and consumer protection regulations.
The Robert Koch-Institute as publisher of the app will trigger this check for the respective countries and release the app after successful legal examination. In a first step, the RKI will release the app for some European countries. These are: Netherlands, Belgium, Luxembourg, France, Austria, Czech Republic, Poland, Denmark, Romania and Bulgaria. It may still take a few hours to a few days until the app is available for the individual countries. We kindly ask you for your patience.
More countries are currently being checked and will be released in the App Stores step by step. The Robert Koch-Institute asks for your understanding that it cannot provide any information on specific countries and the status of their release during the ongoing review process.

We will move this issue to cwa-backlog and add comments for each country or set of countries which are added over time. As said above now we have:

Netherlands
Belgium
Luxembourg
France
Austria
Czech Republic
Poland
Denmark
Romania
Bulgaria

We will close this issue, but we will keep one issue open in our backlog repository, this is https://github.com/corona-warn-app/cwa-backlog/issues/9. See the comment https://github.com/corona-warn-app/cwa-backlog/issues/9#issuecomment-648745301 how to show your support for additional countries.
Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team

Dear colleagues,
finally we have an official statement from the Robert Koch-Institute which is also reflected in our FAQ: https://www.coronawarn.app/en/faq/#international and https://www.coronawarn.app/de/faq/#international

After a detailed examination of the situation it was determined that for legal reasons any publication of the Corona-Warn-App in App Stores outside of Germany is currently only possible after a case-by-case assessment. Legal consultations have shown that in the case of publication in international App Stores, the law of the respective country must be considered and applied to the Corona-Warn-App. This applies in particular to data protection, any necessary claims for information by local authorities and other contractual and consumer protection regulations.
The Robert Koch-Institute as publisher of the app will trigger this check for the respective countries and release the app after successful legal examination. In a first step, the RKI will release the app for some European countries. These are: Netherlands, Belgium, Luxembourg, France, Austria, Czech Republic, Poland, Denmark, Romania and Bulgaria. It may still take a few hours to a few days until the app is available for the individual countries. We kindly ask you for your patience.
More countries are currently being checked and will be released in the App Stores step by step. The Robert Koch-Institute asks for your understanding that it cannot provide any information on specific countries and the status of their release during the ongoing review process.

We will move this issue to cwa-backlog and add comments for each country or set of countries which are added over time. As said above now we have:

Netherlands
Belgium
Luxembourg
France
Austria
Czech Republic
Poland
Denmark
Romania
Bulgaria

We will close this issue, but we will keep one issue open in our backlog repository, this is corona-warn-app/cwa-backlog#9. See the comment corona-warn-app/cwa-backlog#9 (comment) how to show your support for additional countries.
Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team

how about the other countries?
See in Wikipedia: Germany is home to the third-largest number of international migrants worldwide,[10] In 2016, around 23% of Germany's population do not hold a German passport or are descendants of immigrants.[55]
reference:  https://www.destatis.de/DE/Presse/Pressemitteilungen/2017/08/PD17_261_12511.html
https://en.wikipedia.org/wiki/Demographics_of_Germany#Foreign_nationals_in_Germany
most of the western part of the country contain hell lot of people with immigration background:
https://upload.wikimedia.org/wikipedia/commons/8/8e/Germans_without_a_migrant_background_(2016).svg

Sorry for being a bit blunt, but I feel the urgent need to point that out:
How can your legal team not understand that AppStore countries have nothing to do with actual restriction? It has been mentioned several times across all threads and on different platforms. Do they even read the discussion here?

Sorry for being a bit blunt, but I feel the urgent need to point that out:
How can your legal team not understand that AppStore countries have nothing to do with actual restriction? It has been mentioned several times across all threads and on different platforms. Do they even read the discussion here?

Agreed. If it has to be restricted it should be done with other geofencing methods not the country of the app store.

Dear colleagues,
just to be crystal clear: It's the legal team and the responsible people at the Robert Koch-Institute who make the decisions. We can only present the results and offer a channel to raise your voice concerning additional countries. Please see https://github.com/corona-warn-app/cwa-backlog/issues/9#issuecomment-648745301 as already mentioned above.
Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team

just to be crystal clear: It's the legal team and the responsible people at the Robert Koch-Institute who make the decisions.

Then can't you ask the responsible people at RKI to submit themselves to scrutiny in this thread? That's how good decisions are made.
Let's have a few people test and challenge their point of view and see if they have good arguments to defend their position.

Dear @kennethmac2000,
well, I have been investing a considerable amount of my working time over the last days on working together with the responsible people at RKI and the respective legal team. I'm afraid that's the best we can get for now...
Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team

@SebastianWolf-SAP Having some experience working with large organizations and lawyers, I agree that what you've come up with is a pretty good compromise - nice work. I think everyone (even the lawyers!) can agree that it isn't ideal, but at least there's a path forward, and it's great that progress is being made, however slowly. I'm sure you're using demographic data to prioritize countries, as well as our Github likes, and that's great.
@kennethmac2000 @dewey @treysis Actually I completely agree with you that the App Store country is not the real issue, but the reality is that there's no chance that the lawyers for a large company or the government will come on here to discuss. There is a path forward, and we can even have a say in the prioritization, and that's surprisingly helpful, all things considered.

Sorry for being a bit blunt, but I feel the urgent need to point that out:
How can your legal team not understand that AppStore countries have nothing to do with actual restriction? It has been mentioned several times across all threads and on different platforms. Do they even read the discussion here?

We addressed exactly these points to the responsible people at the very beginning, including an estimation how many people living in Germany are affected. Everything was and is on the table and the RKI needed to decide on country by country because of legal reasons (see our FAQ).

Furthermore, the whole process aside from actual programming seems very intransparent. You should publish the analysis on why this restriction is necessary. To most it still doesn't make any sense and it seems like RKI is trying to hide something. Don't you see how you're supporting all people that are against this app? This is not limited to the availability issue, but the general way community requests are handled. Most contributors here want the app to succeed and are using their spare time to comment. But they often just get stonewalled, as if you're trying to hide or avoid any negative PR.

I can only underline that we as the Open Source Team are as well nothing more than messengers here and we don't hide anything with respect to the background. Quote:

Legal consultations have shown that in the case of publication in international App Stores, the law of the respective country must be considered and applied to the Corona-Warn-App. This applies in particular to data protection, any necessary claims for information by local authorities and other contractual and consumer protection regulations.

Once again: The decisions are made at RKI and we do our best to channel the feedback of the community back to them. We have done that repeatedly and this is the result.
Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team

@SebastianWolf-SAP I wanted to make a second comment to thank you and the team for your hard work behind the scenes, as well as your transparency and communication on here. I'm sure it's not easy on many fronts, and we all appreciate your efforts to get this app out as soon as you have. Notably, for instance, Canada's version won't be available until next month, and is far less transparent - there's certainly no Github repos for it. Great work everyone, thank you.
(And please pass this on :) )

I'm 100% with you @bmulholland - massive thanks to @SebastianWolf-SAP for keeping us informed on this and for following it up - I'm so grateful to see actual action being taken in response to things raised here. Of course the perfect solution would be complete availability in all app stores but I am far from an expert here and I understand from my own job that things are not always as simple as the public would expect.
So thank you, thank you, thank you for all of the engagement, long may it continue!! As a reminder of what @SebastianWolf-SAP  said - either add your country here https://github.com/corona-warn-app/cwa-wishlist/issues or get voting if your country is already there - that way we can continue to drive improvement :)

Dear @kennethmac2000,
well, I have been investing a considerable amount of my working time over the last days on working together with the responsible people at RKI and the respective legal team. I'm afraid that's the best we can get for now...
Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team

Thank you for those efforts, even if I disagree with the outcome. :)

literally data security and old habits will kill once this country ;-) or its already on the way?

RKI just announced that the issue is improving for some stores:
https://twitter.com/rki_de/status/1276071687780536320?s=20

It's not a fault of anyone at SAP / RKI, I guess the procedures are formulated this way, but it seems overly cautious to be so concerned about "breaking the law" of another country in this situation. It's beyond obvious that nobody would sue Federal Government for releasing COVID app "on the territory" of foreign country, probably most of the countries do not even consider releasing something in worldwide App Store as releasing it "on our territory". I wish it would simply be possible to click the button "release worldwide" and worry about consequences later (which beyond any doubt would never come). I have a feeling that Italian Ministry of Health who released the app worldwide is not concerned at all about impending court case at ECJ. But I'm happy some moves and analysis are being made, let's hope it will conclude soon.

probably most of the countries do not even consider releasing something in worldwide App Store as releasing it "on our territory".

Exactly this. AppStore country doesn't have any legal implications.

probably most of the countries do not even consider releasing something in worldwide App Store as releasing it "on our territory"

I can see how you can construct an argument that such a release could be so construed, but to lean on that argument is at the extreme end of cautious. How much precedent is there for countries, or residents of those countries, scraping the App Stores for apps which are in violation of the law in those countries? Supposing Corona-Warn-App was considered to be such an app, in which court or tribunal would anyone even be able to take any action against RKI or the German federal government?
Part of the job of being a lawyer is to balance technical possibility against realistic probability and advise accordingly. Especially given the current public health situation, this decision seems like an abundance of caution which is unmerited, and ultimately is putting legal perfection above human health.

Am I misunderstanding something here? The problem is that this app has the ability to communicate with the RKI and it's not legal for them to process data from people in other territories?
Doesn't this app just gather Bluetooth identifiers and give it's own to other apps on request. If I'm using this application in Brazil, I'm merely exchanging Bluetooth identifiers with others.
Then I'm downloading an apple/google managed database of identifiers into my phone for matching against those that I store.
How does the RKI come into this if I'm merely using this functionality alone? Isn't that a globally functional system which doesn't require any country nor infrastructure to operate?
I'm deliberately excluding the testing and verification stages of being infected, etc, etc. Let me split that issue apart for a second.
But have I got this correct so far?

@kennethmac2000 good points, the only realistic option I see for other countries to retaliate against Federal Government for releasing app "on their territory" (meaning in corresponding App Store) is through international sanctions, or trying to raise the issue at European Court of Justice / United Nations forum. I highly doubt it would even worsen international relationships even in the slightest, actually the only result of releasing it worldwide seems to be improvement of international relationships, since it's a nice gesture to allow foreign citizens often travelling / working in Germany to participate in contact tracing system (which also improves safety in foreign countries, as these returning foreign citizens would know their exposure status).
@christhomas that's right, unless you get tested and decide to share your random IDs then RKI does not even know that you are using the app, there is no data exchanged with the servers except for downloading random IDs of infected people (which is actually available worldwide already, you can query this endpoint wherever you are, it's not restricted only to Germany).

Well then I don't see why this app can't be launched worldwide. If I'm travelling to Africa, it'll still work. Or I'm vacationing in Thailand and I find an alert. Can't I just go to a Thai clinic, get tested, then use the same TAN/QR system in that country to upload my results and trigger an alert for other people?
I always thought that was the endgame. I mean, I understand that the RKI is responsible for testing, therefore it has to process your data, but to be tested by the RKI, I would have to be in Germany. If I'm in Germany and I get tested, I can give consent for the RKI to put my results online and use the app to validate the request.
Then all that matters if that I trust each country to upload the correct data to the system and I guess I'll have to judge on a case by case basis whether that country will treat my data securely. Or whether I will take a risk and let them copy my data in exchange for validating my results. I guess I'll have to make a judgement call which is more important in that scenario.
I can't see this data being very valuable to other people and maybe my test result is more valuable than whatever perceived risk there is.
But surely I would have to make that judgement, based on the scenario given. Maybe I'm triggered with an alter whilst in Argentina. Then what?
So my understanding of the app was that it would work anywhere, the system of TAN/QR is safe enough to encrypt whatever data and decrypt it, depending. Then where is the problem?
Seems the problem is just on my shoulders to validate personally whether I trust the healthcare provider giving me the test in whatever country I'm in. That's a problem tech can't solve. Maybe I don't trust the RKI either, then what? You know what I mean?

@christhomas I think the problem of being able to submit your random IDs after you were diagnosed in another country is a great point - but I can understand that getting this process going would require more effort as RKI would have to established the trust with foreign laboratories.
Regarding just notifying you that you were in contact with infected - you are right that app will work worldwide - if you travel to Africa after spending some time in Germany, and someone with whom you were in contact in Germany tests positive and uploads Diagnosis Keys to RKI you will still get alert, no matter where you are. This is because Diagnosis Keys are available worldwide.
The unfortunate part here is that even if you are in Germany all the time, but happen to have foreign App Store, there is no way right now to use the app and receive exposure notification - and this part of functionality does not involve any processing of your data as everything happens on the phone.

So it's clear that every part of this app will work worldwide, including downloading of infected identifiers and uploading your own in case you are deemed infected. Because all of this communicates with apple/googles worldwide infrastructure and it doesn't matter where you are or which app you downloaded. They are all the same when it comes to this side of the functionality. Apple/Google approve the apps depending on their submissions processes.
So that's clear.
The problem is the test results phase.
So from what I understand, you get yourself tested and you get a certificate which needs to be input/scanned into your phone to approve the upload of the data. The lab, uploads the data, encrypted against the information on the certificate to the global apple/google infrastructure.
That data can't be unlocked without my consent. Which is why I have control over the process. So I have this TAN/QR code system to enter the decryption data.
If the lab is giving me a certificate needed to decrypt the data, the lab is going to upload the encrypted version of it. And to decrypt the data I need to input/scan the data on the certificate I get in my hand when I am tested. Then what part of this requires the RKI to do anything at all?
The lab controls the upload process, they generate the decryption certificate themselves and give it to me. It could be any lab doing the testing, as long as I trust them and as long as I scan the code, then my diagnosis is uploaded and decrypted.
To prevent unauthorised labs from uploading bogus data, a lab key + client key, could be used to ensure the final encryption secret is only possible from authorised labs. Such as those from government institutions, same as the approval process for the apps themselves have to be authorised by google. The lab registers it's keys with apple/google infrastructure.
What part did I miss out? Seems fairly simple.

@christhomas

So it's clear that every part of this app will work worldwide, including downloading of infected identifiers and uploading your own in case you are deemed infected. Because all of this communicates with apple/googles worldwide infrastructure and it doesn't matter where you are or which app you downloaded. They are all the same when it comes to this side of the functionality. Apple/Google approve the apps depending on their submissions processes.

There are two parts in play: Google / Apple framework which exists only on your phone, and with which the app communicates. This communication happens only locally on the phone. There is also RKI / Telekom infrastructure which serves as distributor of random IDs of infected people, and provides services to deliver test result and to accept uploaded random IDs.

So from what I understand, you get yourself tested and you get a certificate which needs to be input/scanned into your phone to approve the upload of the data. The lab, uploads the data, encrypted against the information on the certificate to the global apple/google infrastructure.

That's not exactly how it works, there is no global Apple/Google infrastructure in play. The lab uploads data to RKI / Telekom infrastructure, and app communicates over the internet only with the latter.

That data can't be unlocked without my consent. Which is why I have control over the process. So I have this TAN/QR code system to enter the decryption data.

You can always access your data yourself, without a need to have valid TAN/QR code. Perhaps you'd need to have jailbroken iPhone or rooted Android to do it, but in principle you are the master of your device and can extract whatever information you want anytime.

The lab controls the upload process, they generate the decryption certificate themselves and give it to me. It could be any lab doing the testing, as long as I trust them and as long as I scan the code, then my diagnosis is uploaded and decrypted.

Diagnosis Keys are not encrypted (although they are in a form which mathematically ensures your privacy), and in principle you can try to upload them anytime to RKI / Telekom infrastructure. But together with this upload you have to upload valid TAN, which you receive from RKI after positive test, otherwise these Diagnosis Keys will be rejected by the server. So this is where RKI comes it to play - you can upload Diagnosis Keys to RKI / Telekom infrastructure only after being approved by RKI to do so.
What makes this App Store availability problem especially confusing is that there is no real personal / health data processed by the app. I'm not sure what other counties could even complain about if it is deployed in "their country's App Store".
We can at least be happy that Google / Apple did not have such considerations with deploying Exposure Notifications framework worldwide, it would be huge problem if they suddenly decided to push update only to US App Store until they can discuss with each country case-by-case if it would be ok to also push the update there. And I guess it's much easier to sue / retaliate against Google / Apple than against German Federal Government.

My main point: for non-EU Android users -  a simple solution is to create a new (perhaps temporary) Google account and register it in Germany. Doing this allows you to retain your existing account stuff and also get the app. I ran into the same problem when I arrived in Germany; I took the awkward - long swab to the very back of the sinus test - at the airport and was given a paper with a QPR code, but was unable to register it to view my results.  I knew I could change my Google Play account country, but did not want to deal with the "only move once a year" hassle and lose access to US apps (e.g. like bank apps) or subscription services.  In the end, the simple solution was to:

Create a new Google Account
Set up the new account as from Germany in the Play Store.
Point to your new account in Google Play (from the link in step 2, click on  for steps on how to do this)
Download the COVID-Warn-App.

I now have a DEU google account that has the COVID-Warn-App. I was able to scan my QPR and receive my results ("diagnosis: SARS-CoV-2 Negative" -yay) and I can now participate in the anonymous contact notification.

still not available for non-german app store users it seems? that's really bad and has real-life consequences.

@dret the app is available in a variety of international stores https://www.coronawarn.app/de/faq/#international

@dret You can use my python script at https://github.com/treysis/playstore-country-check to check the availability for certain countries.

@tkowark i don’t see why this issue should be unpinned, there are still many country app stores that do not serve the app. It seems a bit much to expect any person arriving in Germany from one of these countries to follow a closed issue on the source code repo.

That's all done in the wishlist repository, now. The store availability is just not an issue for the repository concerned with technical aspects of the app and also needs to be solved for both apps centrally by the publisher and their legal councils.

And the issue to follow now is this one here: https://github.com/corona-warn-app/cwa-backlog/issues/9


Launch error on OS X 10.11.3

I get this error upon launch:
Uncaught Exception:
Error: Cannot find module 'electron'
    at Function.Module._resolveFilename (module.js:336:15)
    at Function.Module._load (module.js:286:25)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at Object.<anonymous> (/Applications/Git-it.app/Contents/Resources/app/main.js:4:11)
    at Module._compile (module.js:430:26)
    at Object.Module._extensions..js (module.js:448:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Object.<anonymous> (/Applications/Git-it.app/Contents/Resources/atom.asar/browser/lib/init.js:108:10)

Eek I think I must have messed up the last release :grin: Will maybe have to do something funky to fix it since I've changed master. But I'm on it :+1:

I've made the fix and it launches on my computer, but if you could, give the OS X version on this release a go and let me know if it doesn't work out: https://github.com/jlord/git-it-electron/releases/tag/3.1.0

This worked for me now. Thanks for creating this!


Ingress not working when opening WebUI from an URL with a non-default portnumber

When using ingress to show the admin-page (Open Web UI), the page won't load when your HA installation runs under an URL with a portnumber other then 80 or 443.
Rootcause: Ingress proxy is not sending correct portnumber in Host-header to internal upstream server.

Fixed in 1.0.1

Had to pull 1.0.1 due to docker image corruption in upstream dependency.
Notified author.

Released version 1.0.2, where platforms aarch64 and armv7 are no being correctly cross-compiled.


PIDP-810 Update keycloak with College Licence JSON

Need to run the keycloak account creation data migration before merging this PR


show_result (inference mode) crashes jupyter notebook

When using show_result for inference predictions, it will crash jupyter notebook.
I have isolated this to the lines:
 mmcv.imshow_det_bboxes(
        img.copy(),
        bboxes,
        labels,
        class_names=class_names,
        score_thr=score_thr,
        show=out_file is None,
        out_file=out_file)

It looks like mmcv.imshow doesn't play well with jupyter notebooks, and it's a known issue.
https://stackoverflow.com/questions/46236180/opencv-imshow-will-cause-jupyter-notebook-crash
Is there a workaround for this?

You may use matplotlib if you are using jupyter notebook to run the demo.
Related to https://github.com/open-mmlab/mmcv/issues/34


Plot labelling

Can you label the plots more clearly with a title??

plot.py has been updated and pushed

You haven't fixed this!!! Change the titles please to include Intravenous or Subcutaneous in the title of the model

Titles have been changed with correct model name
Also, plots are given unique names and solved to a folder in directory

Nice job!!


Multiple ios 8 devices

Is there a known way to get homebridge working with more than one ios 8.4 device at the same time?
When my light devices are assigned to an ios 8 device then other ios devices can not find them (eve app). Devices that are not assigned could be used. Trying IOS 9 beta 2 did not work for me at all because "eve" could not access icloud homekit database for an unknown reason.
Thanx in advance.
PS: using FHEM platform shim which can be found here (german thread): http://forum.fhem.de/index.php/topic,32652.msg314166.html#msg314166

So this is "by design" to comply with Apple's new requirement in iOS 9 for Accessories to only be able to pair with one phone at a time. See HAP-NodeJS Issue #69 for more details:

It seems that iOS 9 starts enforcing the requirement that one accessory can only be paired directly with one iCloud account.

Note that once you pair with the first device, you can invite other HomeKit users to your Home and they will be able to use the accessories.

Can we not spawn another instance listening on a different port?

@wbros Sure, that would technically work as well.


WIP: add mTLS

Adds dedicated mTLS enabled endpoint, see: https://github.com/moul/grpcbin/issues/147

Hey @moul – sorry for the long delay.
I updated that PR with a more straightforward solution. I just added a new flag that enforces client-cert authentication. This solves my issue writing the e2e test and probably has less impact.


Allow users to resume upgrade execution by using resume.sh wrapper

This update includes a wrapper script written by Evan which receives a list of commands to execute on stdin. If an error occurs while executing a step, the script informs the user and gives instructions for resuming.
Closes: #324

Looks about right

Two small things that are mostly clerical - It'd be preferable to have this squashed, and also remove the issue number from the commit message.
The code looks good and makes sense to me, though.

do we care about licensing?

other then that and squashing I like it

sorry to come in late on this, but wouldn't it be possible to just have all this logic in the upgrade script and have a '--resume' flag that we pass if we need to resume? Otherwise we just have wrappers wrapping wrappers all over the place
resume.sh > upgrade.sh > run-upgrade.sh / deploy.sh

Yeah, the concept was that we make resume.sh generic enough to use elsewhere...however, I think if this isn't going to make 11.0.0, we should just move the logic to an Ansible playbook, at this point.

The more I think about this approach, the less I like it. This method means we need to make changes in two places many times which we will mess up. In addition, there are tons of corner cases where this won't work (loops, if statements, etc.).
:-1:

Abandoned


make router sensitive

Type

🔧 Fix
Value

Things work as you expect them to. Who thought insensitive would be the default. Crickey.
Screenshot

Checklist
All

[x] Demoed to the relevant people
[x] PR labelled and assigned
[x] Any introduced code complexity has been flagged

UI component only

[x] A11y tested: npm run test:accessibility <URL>
[x] Browser tested: npm run test:browsers <URL>
[x] Works without JS in the client
[x] Relevant tracking/monitoring has been considered

Merging again as it's broken... apologies.


Better Sidebar

The current implementation of the Sidebar and Mobile Navigation are nice but not optimal. I like the approach apple has used on the developer side and on their main page.
Putting ether the right and middle elements from the topbar into a popover or a fullscreen list of items,
and the sidebar, still as a sidebar but not with 100% width but with the native one and a nice dark overlay beneath it.

I'm having this problem right now with Human Connection. check me through cion. how can make a useful contribution.
there is also no direct responsive header-menu as example.
the sidebar should be fixed and dynamic.
i just give it a try.


Extensions cannot activate with allowJs compiler option

VSCode Version: 1.8.1
OS Version: Ubuntu 16, Linux x64

Steps to Reproduce:

Create a new extension using yo generator-code
Build, debug and activate the new extension to check it works.
Add a pure JavaScript (.js) file to the project.
As per the documentation, add the following to compilerOptions in tsconfig.json:

"allowJs": true

Relaunch the debugging session. The extension now fails to activate.
Remove the allowJs option from compilerOptions and restart debugging. The extension is able to activate again.

The errors reported in the debugger console when the extension fails to load always look like this:

Activating extension myextension.foo failed: {1}.
Activating extension myextension.foo failed:  undefined
Here is the error stack:  undefined

I've tried manually adding the --allowJs option into .vscode/tasks.json - with the same result.

Did you generate a TS or JS extension when using yo

It was a TS extension (otherwise the allowJs option would not be necessary).
I'm closing this because it turned out that the problem was due to the newly added file itself - an exception was being thrown during the loading of the JavaScript module.
It's confusing that there's no error or stack trace to show this (as there normally is a node application). Maybe that should be created as a separate issue?


Rename PMD ruleset.xml to pmd.xml

@artem-zinnatullin
I just realised the name is a bit ambiguous.

My fault too, thanks!


[jax2tf] Fixes for handling of opaque dtypes for slice/update_slice/g…

…ather

It was somewhat lucky that I discovered this: we had the test_prng created a few days ago, and then I discovered that many shape polymorphism tests were only doing the conversion and constructing the tf.Graph, but not running it. Once I started to run the converted function I got these failures.
I am actually concerned that there are many more places where opaque types should get involved in jax2tf, e.g., everywhere we call _eval_shape. Also in no_xla_impl.py. I wish we had a better way to deal with them, e.g., a way to rewrite a JAX eqn to eliminate opaqueness.

To address a broader question raised here, and arguably in a recent PR or two as well, I think what we're seeing are the advantages of opaque dtypes "lowering to physical jaxpr" (i.e. without opaque dtypes), rather than lowering directly to MLIR. Basically as you say:

I wish we had a better way to deal with them, e.g., a way to rewrite a JAX eqn to eliminate opaqueness.

I think we should try to do this. It would simplify things and still seems to capture current use cases. In a conversation we had today, @mattjj also highlighted that resolving opacity within Jaxpr is easier for supporting multiple backends. We initially added opaque dtype lowering thinking about a single backend (MLIR), but not many of them (jax2tf, etc.).


Fuse based overlay filesystem

While ocis is going to use reva storage drivers to wrap the underlying storage capabilities as closely as possible it is not going to try and squish in missing storage aspects (eg. etag propagation, trash, versions, sharing, file lookup by id) into the storage driver.
etag propagation for example can be implemented in the storage driver itself, using inotify, kernel audit hooks or as a file system.
We want to separate the concerns further, and are currently looking into a fuse based overlay filesystem that can propagate the etags, but is otherwise transparent and forwards all requests to the underlying storage.
The approach has appealing properties:

proper separation of concerns
etag propagation works, even when sshing into the machine
tree size accounting can be implemented as well
trash and versions can be implemented by intercepting fclose
an audit log can be written, even when sshing into the machine

etag propagation and size accounting could be implemented by setting an extended attribute in the fs that marks a folder as the root of a tree, similar to how eos does it to detect how far an etag should be propagated

It does have drawbacks:

A file system like this needs to be mounted by root (a download and run would be harder to implement)

related https://github.com/owncloud/ocis-reva/issues/124

Please open again if the ticket is still relevant


How to enbale RTS/CTS handshake?

Since RTS/CTS handshake is disabled by default, I'm wondering how to enable this feature. Is this supported?
Thank you.
@cmaglie

It looks like you can just call these methods
SetDTR(dtr bool) error
SetRTS(rts bool) error

They tell the OS what to do and that's that. So maybe you need to check the Win32 or Linux documentation. Perhaps something you need is missing.


Add finalize relatedness HT option that also adds a relationship annotation for each pair

This PR will not pass tests until the related PR in gnomad_methods gets merged: https://github.com/broadinstitute/gnomad_methods/pull/511
The cuking relatedness results are here: gs://gnomad-tmp/julia/relatedness/gnomad_v4_relatedness_final.html

I added an annotation for v3/v4 overlap to the finalized relatedness HT

Looks like black is failing -- curious if your local instance says the file is fine?


WIP: python3 + omnibus

WIP

Closing PR since we went another way to dynamically load python (rtloader).


deps: Upgrade Flutter, handling new deprecations in Flutter's Color API

Other than the commented issue. This LGTM!

App built with flutter run --release fails for me on API 34 emulator:
✓ Built build/app/outputs/flutter-apk/app-release.apk (31.0MB)
Installing build/app/outputs/flutter-apk/app-release.apk...        538ms

Flutter run key commands.
h List all available interactive commands.
c Clear the screen
q Quit (terminate the application on the device).
W/FlutterEngineCxnRegstry( 4681): Attempted to register plugin (D2.a@e322264) but it was already registered with this FlutterEngine (M2.c@f2b4ccd).
W/FlutterEngineCxnRegstry( 4681): Attempted to register plugin (G2.a@4828bce) but it was already registered with this FlutterEngine (M2.c@f2b4ccd).
W/FlutterEngineCxnRegstry( 4681): Attempted to register plugin (G2.a@13f96da) but it was already registered with this FlutterEngine (M2.c@f2b4ccd).
E/flutter ( 4681): [ERROR:flutter/runtime/dart_vm_initializer.cc(40)] Unhandled Exception: PlatformException(channel-error, Unable to establish connection on channel., null, null)
E/flutter ( 4681): #0      PathProviderApi.getApplicationSupportPath (package:path_provider_android/messages.g.dart:65)
E/flutter ( 4681): <asynchronous suspension>
E/flutter ( 4681): #1      getApplicationSupportDirectory (package:path_provider/path_provider.dart:78)
E/flutter ( 4681): <asynchronous suspension>
E/flutter ( 4681): #2      LiveGlobalStore._dbFile (package:zulip/model/store.dart:643)
E/flutter ( 4681): <asynchronous suspension>
E/flutter ( 4681): #3      LiveGlobalStore.load (package:zulip/model/store.dart:623)
E/flutter ( 4681): <asynchronous suspension>
E/flutter ( 4681): #4      _GlobalStoreWidgetState.initState.<anonymous closure> (package:zulip/widgets/store.dart:63)
E/flutter ( 4681): <asynchronous suspension>
E/flutter ( 4681):
W/FlutterEngineCxnRegstry( 4681): Attempted to register plugin (D2.a@fcbb8e9) but it was already registered with this FlutterEngine (M2.c@94ae96e).
W/FlutterEngineCxnRegstry( 4681): Attempted to register plugin (G2.a@71dfaa5) but it was already registered with this FlutterEngine (M2.c@94ae96e).
W/FlutterEngineCxnRegstry( 4681): Attempted to register plugin (G2.a@e59262b) but it was already registered with this FlutterEngine (M2.c@94ae96e).

Found the (first) Flutter SDK commit which started breaking: https://github.com/flutter/flutter/commit/b2de4dfc2bd222f69680d1c53bbe36a81107b9c9
Not sure what triggers it, but everything works fine when doing a release build with -Pshrink=false:
flutter run --release -Pshrink=false

Tried with upgraded packages (specifically path_provider_android), still same issue.

Looks like using "proguard-android-optimize.txt" by default for release builds breaks it. Might have something to do with the path_provider plugin not being registered?

Perhaps we will want to enable optimization eventually. A fix like this might work for now as we need to handle the new deprecations.
diff --git a/android/app/build.gradle b/android/app/build.gradle
index 87c532b9..d70f10f8 100644
--- a/android/app/build.gradle
+++ b/android/app/build.gradle
@@ -76,6 +76,9 @@ android {
         release {
             signingConfig project.hasProperty('signed') ?
                     signingConfigs.release : signingConfigs.debug
+            proguardFiles(
+                    getDefaultProguardFile("proguard-android.txt"),
+            )
         }
     }

I was able to reproduce it with the scratch template app and reported it upstream — https://github.com/flutter/flutter/issues/154580

With https://github.com/flutter/flutter/pull/154677 and https://github.com/flutter/flutter/pull/154715 merged in the Flutter tree, the issues in the release builds are now gone. So, we can now update to latest main here.

OK, revision pushed, now to take current Flutter main, and with the reimplementation of .value.

Greg, would you take a look at https://github.com/zulip/zulip-flutter/pull/923#discussion_r1739614621 to see if you know what's going on there?

Thanks @chrisbobbe for taking care of this migration, @PIG208 and @rajveermalviya for the reviews, and @rajveermalviya for pursuing and fixing that issue https://github.com/flutter/flutter/issues/154580 upstream!
On the sky_engine version number, I replied at https://github.com/zulip/zulip-flutter/pull/923#discussion_r1747871287 .
This all looks good; merging.


updated aad image

@SharS - this is an image you worked on recently. Would you review this contributor's proposed changes and advise on whether to accept or not?

@LolaJacobsen

@LolaJacobsen - just FYI - I asked @scanum to tag you so this shows up in your query of @ mentions for follow up. Just FYI in case you wonder why you were tagged there. :)

Thank you for the new image. It will need to go through our art process before it can be added to the article. That process can take up to 2 weeks.


fix(typing_manager): Optimize Non-English input method cause replace previous chars

Optimize this pr
Also fix #984, fix #989
Solution
Only register replacePreviousChar command when not in insert mode and dispose in insert mode.
And also register compositionStart and compositionEnd commands to listening text composition and then mark it.
And then send text to nvim client when composition end.
I think It's also fix #984 and fix #989 if it works correctly. because it's not register replacePreviousChar in insert mode.

Thank you for the PR! Can you check if the changes I made still work? If so I'll merge.
Please test: @wenfangdu @zuhanit @74th @snaka @vlwkaos
vscode-neovim-replaceprevchar.zip
Rename .zip to .vsix. Note: this also contains some WIP scrolling PRs that got merged to master but won't be released yet.

@theol0403 @BTBMan
Unfortunately, it was not working correctly in my environment.
https://user-images.githubusercontent.com/19329/185721913-d47b5d3d-f627-4467-8162-492b00f868a2.mp4

Me neither, I appreciate the work, but it's worse than #989, the input isn't only flickery, and also trimed:

I tested 0.9.0, typing Korean works OK.
I think the difference Is because the composition of Chinese or Japanese characters works differently from composition of Korean characters.
As far as I know the former creates a placeholder position(input) for a specific character to be composed by typing--for example roman alphabet--before it actually becomes an input, the latter inputs character as it composes. Maybe this information will help?...

@snaka @wenfangdu Have you tried it to reload window or restart VSCode? Is it still not working correctly after that?

@BTBMan Nope, neither with Sougou Pinyin or Microsoft Pinyin.

@wenfangdu Maybe you can try to reload VSCode window or restart VSCode before test, I'm using Rime on Mac. And I tried to use built-in IME and still working. 😢

@BTBMan I tried reloading multiple times before testing.

@wenfangdu Headache 😖.

@BTBMan The built-in IME (简体拼音) on mac doesn't work either:
https://user-images.githubusercontent.com/28700378/185858087-ddcc00fe-70a3-4464-a09d-3d483d6bf800.mp4

Thank you for the PR! Can you check if the changes I made still work? If so I'll merge.
Please test: @wenfangdu @zuhanit @74th @snaka @vlwkaos
vscode-neovim-replaceprevchar.zip
Rename .zip to .vsix. Note: this also contains some WIP scrolling PRs that got merged to master but won't be released yet.

@BTBMan Can you reproduce using this VSIX file?

@vlwkaos Maybe, But the interesting thing is it will not listening replacePrevChar in insert mode, that is correct. but it's not.

@wenfangdu Whoops. It's not working correctly sometimes... and sometimes. it's working correctly .

vscode-neovim-replaceprevchar.zip
@wenfangdu @zuhanit @74th @snaka @vlwkaos
try to use this test, thanks.

vscode-neovim-replaceprevchar.zip
@wenfangdu @zuhanit @74th @snaka @vlwkaos
try to use this for test, thanks.

@BTBMan This one seems normal.

@wenfangdu Waiting for the test results of other people quietly. 😁

Sorry, I'm late. 😥 It works for me.

Great!

@BTBMan
It looks like OK 👍
Thanks!
https://user-images.githubusercontent.com/19329/186179719-c2c5f933-c029-45a1-9830-845556a23d61.mp4

Hey, Thank you very much for making this contribution!
However, There are some new situations on my side. When using the 4-key select first item feature of Rime input method, There will be the problem of text loss. 🥺

↓ Examples of error:
https://user-images.githubusercontent.com/63690944/189414039-3da99bfd-5f43-4aa1-845c-54cc3c9385d6.mov
↓ Examples of normal:
https://user-images.githubusercontent.com/63690944/189414264-0cf510d4-d5c2-40cb-aabe-b2a42dc90de2.mov

When I press zdup key, The focus should print 自动上屏. But it is currently processed as z自动上.

vscode-neovim-replaceprevchar.zip
@xlboy
Is there a problem if you try to use this for the test?

vscode-neovim-replaceprevchar.zip
@xlboy
Is there a problem if you try to use this for the test?

After testing, it is found that it perfectly solves the problem I described. Thank you!


Increase package meta data cache time

My reason:
The default value 2 minutes is too short for real world, even short than package install time.
So I opened this issue and ask your (the user who reading this issue) opinion about it.
I suggest change it to at lease 5 minutes.

Fixed by #317


视频编码格式

你好，如果要把视频的编码格式换成H264的话需要改哪些内容？

hi, i'm also new member here
i see only place to set h264 is set videoCodec to AV_CODEC_ID_H264 on RecorderParameters.java
but i got the lag video, i dont know why...
@qdrzwd i have no vocabulary to say thanks for great recording lib

Here does not support H264, because I changed something. Javacv native support, you can try to javacv source.

@nguyenvancuongit 改完你说的H264配置后   录制的视频卡帧啊   调参数也不行


Handle focus during connection dialog flow

If you focus the div that is role="dialog" you can back tab out of the focus trap, so I've gone for the first button if it exists instead.


issues on connection to pinecone

Follow the README Instructions i.e., create a .env file and place your pinecone API key and try again.


Implemented fingerprint checks

Good work! Will test extensively and be back (hopefully soon)

Hi! Any updates? Tried your signature?


Optional encoding (Feature request)

In our country we have plenty of sites which are in cp1251 and frequently content encoding detection not working well. So can you add content encoding option when crawling web pages? Currently i use such hack etree_decoded = html.fromstring(codecs.decode(response.content, 'cp1251'))

you can set response.encoding = 'some-encoding' before visite the text content or the tree. It will override the detection behavior(will not auto detect).


feat(ui): add command details on variants commands panel

ANT-2536

3 remarks:

For some reason, when clicking on the button to see the commands list, the front-end does 4 calls (2 times the same 2 calls) and I think it should only perform 2 calls. For long lists of commands it could be a little time consuming

I tested on my local env and even if the back-end sends the info
[{"id":"74403a00-e2a8-454a-aec2-e3770ded7866", "action":"create_area","args": "area_name":"area_1"},"version":1,"user_name":"admin","updated_at":"2024-12-11T16:15:34.281725"}], I see Unknown and unknown for user_name and the date :thinking:

What is the 3 info ? It's written unknown but i don't really know what's supposed to be displayed

3 remarks:
1. For some reason, when clicking on the button to see the commands list, the front-end does 4 calls (2 times the same 2 calls) and I think it should only perform the 2 first. For long lists of commands it could be a little time consuming

2. I tested on my local env and even if the back-end sends the info
   `[{"id":"74403a00-e2a8-454a-aec2-e3770ded7866", "action":"create_area","args": "area_name":"area_1"},"version":1,"user_name":"admin","updated_at":"2024-12-11T16:15:34.281725"}]`, I see Unknown and unknown for user_name and the date 🤔

3. What is the 3rd info displayed in the front ? It's written unknown but i don't really know what's supposed to be displayed

Thanks for the feedback. Let me clarify each point:

Those duplicate API calls should not be due to my recent changes, it's legacy code that's pretty messy. We should definitely rework this view at some point.

About the "Unknown" values, it's intentional that we show "Unknown" as a default state when fields are empty. This maintains UI consistency and avoids having empty/blank spaces in the interface. While you're seeing this now, this case should actually become pretty rare over time, new studies will always have a user and timestamps associated with them. The "Unknown" state mainly exists to handle legacy data or edge cases (fallback)

The third field is just showing the last update time in a human-readable format. see this screenshot:

Reply to Hatim last comment:
1- Indeed it's legacy i just pointed to point it out as you're modifying the view. But if it's too complex to refactor we'll keep it this way
2- I agree that we're not supposed to see any info if the back returns empty values but for new commands you'll have the info and they should be displayed
3- The third field isn't a duplicate of the 2nd ?

I tested on my local env and the bullet points 2 and 3 are resolved IMO


Licensing discussion

To set up issue for discussion on Licensing
Lead discussion

To set up issue for discussion on Licensing
Lead discussion

Examine the license for your project and consider whether this is the choice you want to make, or whether you want to change the license. Discuss and reason the license choice by opening issues in both Python and R repositories. As it is likely to be a very similar discussion for both projects, one of these issues can just link to the other issue where it is thoroughly dicussed.

Examine the MIT license we are currently using
Decide whether we change the license and why
Link this issue to the licensing issue in Python

Hey folks, after checking the https://choosealicense.com/, I think the following license may be some suitable options for our package.

MIT license: short and simple permissive, requiring preservation of copyright and license notices

Permission: commercial use, distribution, modification,  private use
Conditions: license and copyright notice, disclose source, same license, state changes

Boost Software License: simple permissive, requiring preservation of copyright and license notices

Permission: commercial use, distribution, modification,  private use
Conditions: license and copyright notice, disclose source, same license, state changes

GNU GPLv3：strong copyleft, using a licensed work under the same license.

Permission: commercial use, distribution, modification,  patent use, private use
Conditions: license and copyright notice

Apache: permissive, requiring preservation of copyright and license notices.

Permission: commercial use, distribution, modification,  patent use, private use
Conditions: license and copyright notice,  state changes

Personally, I think our original MIT license is the best choice due to the following reasons:

Boost Software License is very similar to the MIT license except that the Boost Software License has license and copyright notice for source, not just only license and copyright notice. I do not this additional condition is necessary for our package. The MIT license is more familiar to most people, which makes life easier for users.

The MIT license has fewer restrictions compared with GNU GPLv3 and Apache. The only restriction an MIT license places on is keeping the license and copyright notice when repurposing, redistributing, or reusing. Given that the nature of this package is a university project, a permissive and open-ended license seems the most reasonable choice.

However, there may be some drawback if we use the MIT license:

If we want to put more restrictions on the future, the process will be very difficult.
It does not explicitly cover patent grants.

Overall, I think base on the nature and main purpose of our package, sticking with MIT license would be a reasonable choice.

Hi @JuntingHe,
Thank you so much for kick-starting this discussion and so beautifully summarizing these different options for us. I agree that the MIT License is the best option given its permissiveness and protection from liabilities.
Best,
Ela

Hi @JuntingHe,
Thank you for the detailed information about each option. I think that the MIT License looks the most appropriate for our project.
Best,
Elina

Hi @JuntingHe! I agree with your assessment.  I think MIT License would suit our package best.

After discussion, our team decided to stick with our original MIT license because it is permissive and familiar to most people. Also, it fits the nature of our package.


FLEX-1737 Changes default exception messages to more specific ones

FLEX-1737 Changes default exception messages to more specific ones.

SonarQube analysis reported 12 issues

 11 major
 1 info

Watch the comments in this conversation to review them.
Top 10 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 DeviceManagementService.java#L72: Remove this unused method parameter "messageType".
 DeviceManagementService.java#L129: Remove this unused method parameter "messageType".
 DeviceManagementService.java#L168: Remove this unused method parameter "messageType".
 ConfigurationManagementService.java#L127: The Cyclomatic Complexity of this method "handleGetConfigurationResponse" is 13 which is greater than 10 authorized.
 ConfigurationManagementService.java#L150: Refactor this code to not nest more than 3 if/for/while/switch/try statements.
 ConfigurationManagementService.java#L168: Refactor this code to not nest more than 3 if/for/while/switch/try statements.
 AdHocManagementService.java#L116: Method has 8 parameters, which is greater than 7 authorized.
 DeviceMonitoringService.java#L90: Replace the usage of the "instanceof" operator by a catch block.
 AdHocManagementService.java#L86: Method has 8 parameters, which is greater than 7 authorized.
 AdHocManagementService.java#L88: Remove this unused method parameter "messageType".

All is well.

SonarQube analysis reported 12 issues

 11 major
 1 info

Watch the comments in this conversation to review them.
Top 10 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 DeviceManagementService.java#L72: Remove this unused method parameter "messageType".
 DeviceManagementService.java#L129: Remove this unused method parameter "messageType".
 DeviceManagementService.java#L168: Remove this unused method parameter "messageType".
 ConfigurationManagementService.java#L127: The Cyclomatic Complexity of this method "handleGetConfigurationResponse" is 13 which is greater than 10 authorized.
 ConfigurationManagementService.java#L150: Refactor this code to not nest more than 3 if/for/while/switch/try statements.
 ConfigurationManagementService.java#L168: Refactor this code to not nest more than 3 if/for/while/switch/try statements.
 AdHocManagementService.java#L116: Method has 8 parameters, which is greater than 7 authorized.
 DeviceMonitoringService.java#L90: Replace the usage of the "instanceof" operator by a catch block.
 AdHocManagementService.java#L86: Method has 8 parameters, which is greater than 7 authorized.
 AdHocManagementService.java#L88: Remove this unused method parameter "messageType".

All is well.


Hi - Pieces "Bank"

Hi,
When using the line shuffle the pieces goes outside of the the canvas.
Is it possible to add a "Bank" of the pieces with
horizontal scroll to it? attached an image

Thanks,

Hi @djroy25,
Unfortunately, there is no current support for pieces' banks like you proposed. However, yoy should be able to control the pieces going out of canvas at some degree. Just use the distance parameter when shuffling the canvas, e.g.  canvas.shuffle(0.8).
I suggest to check the shuffle buttons in the demo at https://flbulgarelli.github.io/headbreaker/. Please check that pieces don't ever - completely - go off-stage.


Make fallback resort to next toggle driver

Why you made the change:
I did this because previously when toggle reconstitution would fail due to a
miss-match, or a missing value, etc. It would simply return a NullToggle. This
short-circuited the process and resulted in the toggle evaluating to false. The
problem was that it was not falling back to the other toggle drivers and
eventually falling back to the defaults held by the in-memory drivers.
I resolved this by modifying the toggle repository get method to check the
success/failure of toggle reconstitution and fall back to the previous toggle
drivers if reconstitution failed. This will make it so that if for any of the
above possible reasons for failure, it will follow the natural driver fallback
path rather than short-circuiting with a NullToggle.

Let's add a new integration test testing that this new fallback process is working.