Support az login --identity for Azure Arc

Is your feature request related to a problem? Please describe.
For enrolled Azure Arc systems, azure-cli does not support pulling the local managed identity.
Describe the solution you'd like
az login --identity tests if running on an Azure instance and if not to fallback to using the localhost challenge response endpoint http://localhost:40342 provided by /opt/azcmagent/bin/himds.
If azure-cli gets this functionality it means I can have my scripts call az ... directly and not have to treat Azure instances differently to on-premise kit; for example to access a shared keyvault or a workspace for logging and metrics.
Describe alternatives you've considered
I have to do the REST dance myself and spoof some credentials for the azure-cli via ~/.azure/{accessTokens,azureProfile}.json.

az login

az login

@jimdigriz We definitely need this.
In the meantime, do you have any bash code that generates a valid token object in ~/.azure/accessTokens.json using the REST API?

Using a managed identity with Arc enabled servers is supported by Azure Identity in https://github.com/Azure/azure-sdk-for-python/pull/15020. The commit https://github.com/Azure/azure-sdk-for-python/commit/d32f4b3a78d41d4f90e2694c69d62b009e5b5dd4 is released in azure-identity_1.6.0b2, azure-identity_1.6.0b1, azure-identity_1.5.0, but the latest Azure CLI beta still uses
https://github.com/Azure/azure-cli/blob/aa456a28c56c8436be1af6e9f2a3e96a21d293f0/src/azure-cli-core/setup.py#L54
which doesn't have this feature.
We will release a new version of Azure CLI beta using azure-identity_1.6.0b2 with support for managed identity with Arc enabled servers.

⚠ Manipulating ~/.azure/accessTokens.json is NEVER a supported scenario. ~/.azure/accessTokens.json will be deprecated in the beta MSAL-based Azure CLI.

I have to do the REST dance myself and spoof some credentials for the azure-cli via ~/.azure/{accessTokens,azureProfile}.json.

This approach will stop working immediately once you start using MSAL-based Azure CLI.

@jimdigriz We definitely need this.
In the meantime, do you have any bash code that generates a valid token object in ~/.azure/accessTokens.json using the REST API?

@richeney Sorry no, I explored this and found the juice was not worth the squeeze; it quickly became apparently that tinkering with accessTokens.json was going to be fragile at best.
In the end I baked the logic into my application and moved on.
Maybe you could slum it with shell wrapper for cURL that then goes and calls az rest --skip-authorization-header --headers authorization=... ...? Awful but it might help you until MS release a new version of the CLI which could be months...

Any hope of seeing this anytime soon?
Just stumble upon it and spent a while trying to understand why the environment variables where not overriding the 169.254* address. (until it occur to me to check on github)

Due to a recent reorganization, we have to delay the development of Azure Identity and MSAL integration. The rough ETA is the end of this year (2021-12-31), but it is not guaranteed.
Thanks for understanding.

Due to a recent reorganization, we have to delay the development of Azure Identity and MSAL integration. The rough ETA is the end of this year (2021-12-31), but it is not guaranteed.
Thanks for understanding.

is this something that could be sped up by merge request / contributions from the community?

We plan to hire more people to contribute to this big project:)

Quite strange to leave out the support for MSI on CLI for hybrid scenarios when one of the core benefits on Arc is that the resource gets an Managed Identity...

@johlindr, here are some Bash commands for Linux that may help you. Needs jq installed and sudoers configured.
imds=$(curl -sSL -H Metadata:true http://localhost:40342/metadata/instance?api-version=2020-06-01)
subscriptionId=$(jq -r .compute.subscriptionId <<< $imds)
resourceGroupName=$(jq -r .compute.resourceGroupName <<< $imds)

# Challenge token
challengeTokenPath=$(curl -s -D - -H Metadata:true "http://<IP_ADDRESS>:40342/metadata/identity/oauth2/token?api-version=2019-11-01&resource=https%3A%2F%2Fmanagement.azure.com" | grep Www-Authenticate | cut -d "=" -f 2 | tr -d "[:cntrl:]")
challengeToken=$(sudo cat $challengeTokenPath)

# Resource token
token=$(curl -s -H Metadata:true -H "Authorization: Basic $challengeToken" "http://<IP_ADDRESS>:40342/metadata/identity/oauth2/token?api-version=2019-11-01&resource=https%3A%2F%2Fmanagement.azure.com" | jq -r .access_token)

# Example ARM REST API call
curl -sSL -X GET -H "Authorization: Bearer $token" -H "Content-Type: application/json" https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/resources?api-version=2020-06-01 | jq .

That last command will only work if the Managed Identity has an RBAC role assignment. Here is the command to get the ObjectId for the Managed Identity.
objectId=$(az connectedmachine show --name <vmname>--resource-group <rgname> --query identity.principalId --output tsv)

You can change the resource from management.azure.com to other resources / audiences to get tokens for other REST API endpoints, e.g. https://vault.azure.net.

but am I able to use the CLI library functions using  the access token manually retrieved for the MSI?  We are using the "manual" approach aleady to perform certain tasks but need to onboard an Azure Arc Kubernetes cluster and not sure I wish to do that with direct API calls.

I'm not going to say anything that isn't already said above:

No, I don't think you can login with the azure CLI on Arc-enabled servers as the managed identity
the work to enable this properly is major as it fundamentally changes the auth method - aiming for end of the CY
others (i.e. @jimdigriz) have tried munging accessTokens.json but have backed away from that as it is fragile

REST API calls it is!

@richeney's comment is correct. This is currently the only way to call Azure APIs from Azure Arc servers.
You may also specify the access token in
az rest --headers authorization="<access_token>"

While we will implement az login --identity for Azure Arc, maybe the "bring your own access token" proposal (https://github.com/Azure/azure-cli/issues/16459) will also make Azure CLI more versatile, so that you may call normal Azure CLI commands with the access token acquired using @richeney's method (https://github.com/Azure/azure-cli/issues/16573#issuecomment-870503359). 🤔

@jsntcy / @yonzhan
Will this be resolved by the July 2021 milestone?
If so, how will the fix be implemented?

accidentally close it, reopen now

Any update on this?

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?

That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread. :)

any update on that feature?

Current technical difficulties:

Azure CLI dropped Azure Identity and now directly uses MSAL for user/service principal authentication
Currently, Azure CLI uses msrestazure for managed identity authentication, but msrestazure has been replaced by Azure Identity and out of maintainance
MSAL has no managed identity support, and it is not planed in the near future (https://github.com/AzureAD/microsoft-authentication-library-for-python/issues/58)

In order to support Azure Arc's variation of managed identity, Azure CLI needs to incorporate msrestazure's code and make changed on top of that.

Provided more information in https://github.com/Azure/azure-cli/issues/24150

Azure Arc's managed identity will be supported by MSAL (https://github.com/AzureAD/microsoft-authentication-library-for-python/pull/480) and Azure CLI will migrate its managed identity authentication to MSAL (https://github.com/Azure/azure-cli/pull/25959). After these tasks are done, Azure CLI will support Azure Arc's managed identity, but currently there is no ETA.

Please, are there some updates ? I need authorize to azure from arc server.

Hi
This is a fundamental ask, which has not been worked on yet.
This scenario is supported by powershell AZ modules.
Can you please proiritize this ?

I came across this long-standing and still unresolved issue while trying to figure out how to execute ray {up|down} from an Azure Arc server as ray seems to depend on the azure cli for this. I don't think anything here can help, but if anyone is just trying to access Azure resources from Python code, the following may be useful. It essentially runs the commands that @richeney listed here but wraps them in Python code and provides a "credential" that we can use to instantiate storage, secrets, and compute management clients. We also use this credential in a slightly different manner to create a pyodbc connection. Here's the code to create the credential and a helper to obtain it that can use the REST API if on ARC or DefaultAzureCredential if not (controlled by an environment variable):
#!/usr/bin/env python
"Authenticate against Azure resources with user, managed identity, or Arc server permissions."

import json
import os
import requests

from azure.core.credentials import AccessToken
from azure.identity import DefaultAzureCredential

def _get_access_token(scope):
    """Get access token from a Managed Identities for Azure Resources service.

    Args:
        resource_type (str): Desired Azure scope to access. "storage.azure.com",
            "management.azure.com", "vault.azure.net",
            or "database.windows.net" are common options.

    Returns (azure.core.credentials.AccessToken): Azure access token.
    """

    # Note: The port will need to be parameterized if the service runs elsewhere.
    resp = requests.get(
        "http://<IP_ADDRESS>:40342/metadata/identity/oauth2/token?api-version=2019-11-01&"
        f"resource={scope}",
        headers={"Metadata": "true"},
    )
    fn = resp.headers["Www-Authenticate"].split("=")[-1]
    with open(fn) as f:
        token = f.read()
    token = requests.get(
        "http://<IP_ADDRESS>:40342/metadata/identity/oauth2/token?api-version=2019-11-01&"
        f"resource={scope}",
        headers={"Metadata": "true", "Authorization": f"Basic {token}"},
    ).content

    token = json.loads(token.decode("UTF-8").strip("\n"))

    return AccessToken(token["access_token"], expires_on=float(token["expires_on"]))

class ARCServerCredential:
    def __init__(self, scope=None):
        """Return credential to work with Arc server.

        Args:
            resource_type (str): Desired Azure scope to access. "storage.azure.com",
                "management.azure.com", "vault.azure.net",
                or "database.windows.net" are common options.
        """
        if scope is None:
            raise ValueError("scope cannot be None.")
        self.access_token = _get_access_token(scope=scope)

    def get_token(self, *scopes, **kwargs):
        return self.access_token

def get_azure_credential(scope=None, **kwargs):
    """Produce a credential accepted by tooling in the Azure SDK for Python.

    Enables authentication using tokens acquired from DefaultAzureCredential
    or, on an Azure Arc server, from an active Managed Identities
    for Azure Resources service.

    Args:
        scope (str): Desired Azure scope to access. Passed to ARCServerCredential.
        kwargs: Arguments to be passed to DefaultAzureCredential.

    Returns (azure.identity.DefaultAzureCredential|ARCServerCredential): Azure access
        token.
    """
    if os.getenv("AZURE_ARC_ENABLED", "false") == "false":
        return DefaultAzureCredential(**kwargs)

    return ARCServerCredential(scope=scope)

We have succeeded in using this approach within containers running on the Arc server. This only requires a couple of flags when executing docker run: --network=host --mount type=bind,source=/var/opt/azcmagent,destination=/var/opt/azcmagent,readonly
If you haven't baked the required env variable into the image, you'll also need to add --env AZURE_ARC_ENABLED=true to the run command

@msalwen, if you are retrieving the access token on Azure Arc by yourself, it is recommended to use MSAL: https://msal-python.readthedocs.io/en/latest/#managed-identity

Now that Azure CLI 2.30.0 has switched to MSAL, and MSAL supports Azure Arc, will this finally get past the deadlock?
@jiasli, will the preview of #29187 enable az login --identity?

Any updates on ETA? This is a very critical feature to have on Arc-enabled servers. Thank you very much!

@msalwen, if you are retrieving the access token on Azure Arc by yourself, it is recommended to use MSAL: https://msal-python.readthedocs.io/en/latest/#managed-identity

Thank you @jiasli. I have reimplemented our code following your suggestion. However, please note that there is a small but significant problem with the implementation of msal.ManagedIdentityClient that requires a workaround (for at least some users). In this object the method _get_arc_endpoint checks whether the path /var/opt/azcmagent/bin/himds exists. On our Arc servers this path does not exist. The executable it is looking for is instead in /opt/azcmagent/bin. The workaround we use is to create the directory /var/opt/azcmagent/bin and hard link himds from /opt/azcmagent/bin into /var/opt/azcmagent/bin. This approach allows the code to run as intended both on the Arc server itself and within a docker container running on that server with the run flags as given in my previous comment. Of course, users should check whether the locations on their Arc servers are as we have found them or as anticipated in msal.
With this adjustment made, we can reimplement the function _get_access_token given above as:
### imports not included above that are now required ###
### Note that we no longer need to import json or os ###

import msal

from requests.adapters import HTTPAdapter, Retry

###########################################

def get_access_token(scope):
    scope = f'https://{scope.replace("https://", "")}' # allow user to pass scope with or without protocol
    mi = {"ManagedIdentityIdType": "SystemAssigned", "Id": None}
    retries = Retry(
        total=3, backoff_factor=0.1, status_forcelist=[429, 500, 501, 502, 503, 504]
    )
    sess = requests.Session()
    sess.mount("https://", HTTPAdapter(max_retries=retries))
    client = msal.ManagedIdentityClient(mi, http_client=sess)
    result = client.acquire_token_for_client(resource=scope)

    return AccessToken(result["access_token"], expires_on=int(result["refresh_in"]) + int(result["refresh_on"]))

which is admittedly somewhat tidier.
@richeney @husamhilal Nothing I've done here moved the needle on being able to log into azure cli using the --identity option, including setting all sorts of environment variables mentioned in various parts of the msal code and docs. The code is still looking for the identity endpoint at the IP 169. ..., which is only reachable within Azure.

will the preview of #29187 enable az login --identity?

@richeney, yes. We plan to include it in Azure CLI 2.67.0 which will be released on 2024-11-19: https://github.com/Azure/azure-cli/milestone/148

@msalwen, I saw you have created https://github.com/AzureAD/microsoft-authentication-library-for-python/issues/762 for the incorrect /var/opt/azcmagent/bin/himds detection path. Once https://github.com/AzureAD/microsoft-authentication-library-for-python/pull/763 is released, Azure CLI will pick up a new MSAL.

@jiasli  is there any (private) preview version I can test, please? (I'm internal to Microsoft)  Thank you!

I have merged https://github.com/Azure/azure-cli/pull/29187 into the dev branch. Managed identity support on Azure Arc-enabled Windows server will be included in this sprint's release:
https://github.com/Azure/azure-cli/milestone/148

Official Release: 11/19/2024
Azure CLI version: 2.67.0

@husamhilal, thank you for your interest. You may find the edge build in the CI pipeline's artifacts:
https://dev.azure.com/azclitools/public/_build/results?buildId=203919&view=artifacts&pathAsName=false

ZIP: https://artprodwus21.artifacts.visualstudio.com/A7b238909-6802-4b65-b90d-184bca47f458/5147fa83-336e-44ef-bbe0-c86b8ae86cbb/_apis/artifact/cGlwZWxpbmVhcnRpZmFjdDovL2F6Y2xpdG9vbHMvcHJvamVjdElkLzUxNDdmYTgzLTMzNmUtNDRlZi1iYmUwLWM4NmI4YWU4NmNiYi9idWlsZElkLzIwMzkxOS9hcnRpZmFjdE5hbWUvemlwLXg2NA2/content?format=file&subPath=%2FMicrosoft Azure CLI.zip
MSI x64: https://artprodwus21.artifacts.visualstudio.com/A7b238909-6802-4b65-b90d-184bca47f458/5147fa83-336e-44ef-bbe0-c86b8ae86cbb/_apis/artifact/cGlwZWxpbmVhcnRpZmFjdDovL2F6Y2xpdG9vbHMvcHJvamVjdElkLzUxNDdmYTgzLTMzNmUtNDRlZi1iYmUwLWM4NmI4YWU4NmNiYi9idWlsZElkLzIwMzkxOS9hcnRpZmFjdE5hbWUvbXNpLXg2NA2/content?format=file&subPath=%2FMicrosoft Azure CLI.msi

Fantastic news. Managed identity on Azure Arc-enabled Windows will be a big win.
I look forward to Azure Arc-enabled Linux being added in once they've updated the MSAL library for Python and finishing this one off!

I have merged #29187 into the dev branch. Managed identity support on Azure Arc-enabled Windows server will be included in this sprint's release:
https://github.com/Azure/azure-cli/milestone/148

Official Release: 11/19/2024
Azure CLI version: 2.67.0

@husamhilal, thank you for your interest. You may find the edge build in the CI pipeline's artifacts:
https://dev.azure.com/azclitools/public/_build/results?buildId=203919&view=artifacts&pathAsName=false

ZIP: https://artprodwus21.artifacts.visualstudio.com/A7b238909-6802-4b65-b90d-184bca47f458/5147fa83-336e-44ef-bbe0-c86b8ae86cbb/_apis/artifact/cGlwZWxpbmVhcnRpZmFjdDovL2F6Y2xpdG9vbHMvcHJvamVjdElkLzUxNDdmYTgzLTMzNmUtNDRlZi1iYmUwLWM4NmI4YWU4NmNiYi9idWlsZElkLzIwMzkxOS9hcnRpZmFjdE5hbWUvemlwLXg2NA2/content?format=file&subPath=%2FMicrosoft Azure CLI.zip
MSI x64: https://artprodwus21.artifacts.visualstudio.com/A7b238909-6802-4b65-b90d-184bca47f458/5147fa83-336e-44ef-bbe0-c86b8ae86cbb/_apis/artifact/cGlwZWxpbmVhcnRpZmFjdDovL2F6Y2xpdG9vbHMvcHJvamVjdElkLzUxNDdmYTgzLTMzNmUtNDRlZi1iYmUwLWM4NmI4YWU4NmNiYi9idWlsZElkLzIwMzkxOS9hcnRpZmFjdE5hbWUvbXNpLXg2NA2/content?format=file&subPath=%2FMicrosoft Azure CLI.msi

Awesome, thank you so much @jiasli , it worked perfectly! Congratulations, and well done!

Amazing. I look forward to testing this out!! Thanks @jiasli.

https://github.com/Azure/azure-cli/pull/30267 has been merged into the dev branch. Managed identity support on Azure Arc-enabled Linux server will be included in 2.68.0 release (2024-12-10).

@richeney, you are mostly welcome. I am also very glad this feature can be helpful to you.
If you like, you may test this functionality by installing Azure CLI from source code:
git clone https://github.com/Azure/azure-cli --depth 1
python3 -m venv azure-cli-env
. azure-cli-env/bin/activate
pip install --no-deps --editable azure-cli/src/azure-cli-core azure-cli/src/azure-cli azure-cli/src/azure-cli-telemetry
pip install --requirement azure-cli/src/azure-cli/requirements.py3.Linux.txt
Once you have finished the testing, you may delete these folders:
rm -rf azure-cli azure-cli-env
DEB and RPM packages are also available at https://dev.azure.com/azclitools/public/_build/results?buildId=207433&view=artifacts&pathAsName=false&type=publishedArtifacts

Awesome. Works on Ubuntu ARM64 (jammy). Thank you!


Automated cherry pick of #7852: fix(notify): pull contact for workwx, dingtalk and feishu

Cherry pick of #7852 on release/3.4.
#7852: fix(notify): pull contact for workwx, dingtalk and feishu

/lgtm
/approve


solved query deadlock- webserver starts query jobs

Regular non-scheduled callback starts the AsyncResult jobs. Then a background callback waits for them and reports completion to the loading animation.
verified that this worked on podman-compose as well, and on low-resources.
also added result forgetting to prevent meaningless task results from stacking up in backend.
Signed-off-by: James Kunstle<EMAIL_ADDRESS>

@JamesKunstle sounds good! Once its rebased ill merged

@cdolfi rebased, should be ready!


Add statuses to Submission elements to indicate whether it is spam

This PR fixes #58.
It:

adds an isSpam column in the contactform_submissions table
adds statuses to the Submission element type
implements the unified element editor

This gives the ability to use the status dropdown in the element index to show only Not spam / Spam submissions or all of them.

The unified element editor :

adds a metadata sidebar with the element ID, status & creation/update dates
adds the ability to open the submission in the editor slideout from the element index
voids the need for a controller

This PR needs #186, otherwise submissions marked as spam by the contact-form-honeypot plugin will be saved as Not spam.

Hi @rosskenney,
Did you get a chance to review this PR? I'm available to make adjustments if needed!

@nstCactus thanks for this and other PRs 🎉 We'll try and review these all soon and appreciate the help with these!


onTokenRefresh does not work on background

Step 2: Describe your environment

Android device: Huawei
Android OS version: 4.4
Google Play Services version: 10.2.1
Firebase/Play Services SDK version: 10.2.1

Step 3: Describe the problem:
i was experimenting to know if onTokenRefresh is called on background and i realized that onTokenRefresh is callled only when i open my app, but is necessary to call onTokenRefresh when the app is on background too
Steps to reproduce:

i call FirebaseInstanceId.getInstance().deleteInstanceId();
i close my app
i wait for a while and onTokenRefresh is called never
i open my app
onTokenRefresh is called finally

but that is the problem, i want that onTokenRefresh be called when my app is closed too

Hacker has control of my Google account through Google development App and
Google security suite , etc ! Controls my devices , PC etc ! I need help !
Call me<PHONE_NUMBER>. And not sure if you will even get this email

@hvar90 Thanks for that feedback. Currently onTokenRefresh is called when a new token is generated. Calling deleteInstanceId() does not automatically trigger the generation of a new token. Try calling getToken after deleting the current token, in that case a new token will be generated and you should see the onTokenRefresh callback whether the app is in the foreground or background.

but, that is not the problem, yes, Calling deleteInstanceId() and calling
getToken after deleting the current token the new token will be generated
but, what happen when  a new token is generated but the app have not been
open during long time ? the new token is generated when i open the app
only, but that is a mistake, because not all the people open the app
frecuently so some messages will be missed
2017-06-30 16:44 GMT-05:00 Arthur Thompson<EMAIL_ADDRESS>
@hvar90 https://github.com/hvar90 Thanks for that feedback. Currently
onTokenRefresh is called when a new token is generated. Calling
deleteInstanceId() does not automatically trigger the generation of a new
token. Try calling getToken after deleting the current token, in that case
a new token will be generated and you should see the onTokenRefresh
callback whether the app is in the foreground or background.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/quickstart-android/issues/256#issuecomment-312379603,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC-b8kN-0w0pLluwMmS7XJ8-H8x-o0erks5sJWxVgaJpZM4NCRkn
.

If a new token is generated when your app is in the background then the onTokenRefresh will be called. You can then use the new token to ensure that your user does not miss messages.

i tested it many times and when a new token is generated when my app is in
the background  the onTokenRefresh is called never. only when i open the
app onTokenRefresh is called or maybe is only on my cellphone huawei but
for me that does not work
2017-07-01 13:03 GMT-05:00 Arthur Thompson<EMAIL_ADDRESS>
If a new token is generated when your app is in the background then the
onTokenRefresh will be called. You can then use the new token to ensure
that your user does not miss messages.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/quickstart-android/issues/256#issuecomment-312446937,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC-b8vgtEyzgaoWMZZbT00K_7kihkfOEks5sJon9gaJpZM4NCRkn
.

Are you sure that a new token is being generated while your app is in the background? It could be that the new token is only being generated when your app is opened and thats why onTokenRefresh is then being called.

but, i mean, when a token is created  it works for a while, after a couple
of weeks or months when the user does not open the app the token expires
and  onTokenRefresh is called never, only when the user open the app
onTokenRefresh is called
2017-07-03 23:19 GMT-05:00 Arthur Thompson<EMAIL_ADDRESS>
Are you sure that a new token is being generated while your app is in the
background? It could be that the new token is only being generated when
your app is opened and thats why onTokenRefresh is then being called.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/quickstart-android/issues/256#issuecomment-312776851,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC-b8hDZQTdIlYQrvK6jB8Uo21cO4uu1ks5sKb03gaJpZM4NCRkn
.

If the token expires while the app is in the background onTokenRefresh should be called. If you are seeing tokens expiring and onTokenRefresh not being called then that is a bug. Note though that deleting a token is not the same as a token expiring.

i have a messaging app and many users when the token expires onTokenRefresh
not being called, with my cellphone occur the same problem when the token
expires
2017-07-04 9:17 GMT-05:00 Arthur Thompson<EMAIL_ADDRESS>
If the token expires while the app is in the background onTokenRefresh
should be called. If you are seeing tokens expiring and onTokenRefresh not
being called then that is a bug. Note though that deleting a token is not
the same as a token expiring.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/quickstart-android/issues/256#issuecomment-312889140,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC-b8kBlWR4CK21NdE7y-CiTVzI9L9OEks5sKklhgaJpZM4NCRkn
.

The tokens should not be invalidated or expired unless the user uninstalls and reinstalls the app or Google invalidates the token for security reasons. A user not using an app for some time should not invalidate the token so there should be no expectation that onTokenRefresh would be called.
Sorry if I am missing your point but could you explain how you know they tokens are expired?

for two things:
because when the tokens are expired we do not receive notifications, only
when we open the app, we can receive notifications
also with my https://pypi.python.org/pypi/gcm-client/ i see many errors
with this message: GCMNotRegisteredException: Registration id is not valid
anymore
2017-07-04 13:48 GMT-05:00 Arthur Thompson<EMAIL_ADDRESS>
The tokens should not be invalidated or expired unless the user uninstalls
and reinstalls the app or Google invalidates the token for security
reasons. A user not using an app for some time should not invalidate the
token so there should be no expectation that onTokenRefresh would be called.
Sorry if I am missing your point but could you explain how you know they
tokens are expired?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/quickstart-android/issues/256#issuecomment-312934177,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC-b8pXcqjZQXRKGhusssYLYBYsx7BqUks5sKojpgaJpZM4NCRkn
.

Thanks, one more clarification: to reproduce, you mentioned that deleting the token.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/quickstart-android/issues/256#issuecomment-312936739,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC-b8htrvfSOrAdJntv7AII0x7eyJf4Pks5sKo65gaJpZM4NCRkn
.

In step 1 of your original post you said:

i call FirebaseInstanceId.getInstance().deleteInstanceId();

I was wondering if you are doing that in your app and if so when are you using deleteInstanceId()?

i tested again and when i use
FirebaseInstanceId.getInstance().deleteInstanceId();
FirebaseInstanceId.getInstance().getToken();
onTokenRefresh is called, so, the problem is only when the token have
expired, onTokenRefresh is called only when the person open the app, also
ir weird that the token expire after the person does not use the app for a
while
2017-07-04 14:24 GMT-05:00 Arthur Thompson<EMAIL_ADDRESS>
In step 1 of your original post you said:
i call FirebaseInstanceId.getInstance().deleteInstanceId();
I was wondering if you are doing that in your app and if so when are you
using deleteInstanceId()?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/quickstart-android/issues/256#issuecomment-312937922,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC-b8o9vtACOZZp_4NNtqrdN49u-7Uxxks5sKpFkgaJpZM4NCRkn
.

If you are using deleteInstanceId then the token will be invalidated and onTokenRefresh would only be called when you call getToken. Are you using deleteInstanceId() in your app?

yes but i use deleteInstanceId only to reproduce the problem, in my app i
dont use deleteInstanceId never
2017-07-04 15:06 GMT-05:00 Arthur Thompson<EMAIL_ADDRESS>
If you are using deleteInstanceId then the token will be invalidated and
onTokenRefresh would only be called when you call getToken. Are you using
deleteInstanceId() in your app?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/quickstart-android/issues/256#issuecomment-312946305,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC-b8hQnqo8lnqIkm82ebuBL8XVldsgVks5sKptfgaJpZM4NCRkn
.

When you get the GCMNotRegisteredException from the library you are using, is there a canonical ID that is returned?

With canonical ID do you mean the firebase token?
Nothing is returned but i could print what ID has expired
2017-07-05 13:39 GMT-05:00 Arthur Thompson<EMAIL_ADDRESS>
When you get the GCMNotRegisteredException from the library you are using,
is there a canonical ID that is returned?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/quickstart-android/issues/256#issuecomment-313190172,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC-b8rGy9-w9XT9FPBJcfwdB8O0QAqgyks5sK9hqgaJpZM4NCRkn
.

If a device has multiple tokens then only the last one should be used. All others may result in Not Registered error and that error should contain a canonical ID (the last token) indicating that that is the one that should be used.
However I think you are indeed experiencing an issue that we should investigate further. Could you file a ticket and include my name Arthur Thompson so that I can continue assisting you with more details about your issue.
I'll close this issue here, looking fwd to your ticket.


CY-3552 Use b64encode for creating credentials.

As opposed to urlsafe_b64encode.
No reason for this to be urlsafe. At all.
Also, urlsafe breaks, because flask uses the non-urlsafe version
when decoding: https://github.com/pallets/werkzeug/blob/bbc5cbb8390d8d9de4fff42456cab3d91b85b584/src/werkzeug/http.py#L622
(this is for making request.authorization, which we then use).
Also, the basic auth rfc (RFC 7617) talks about using the plain version
of base64, not an urlsafe variant.
It needs to be encoded the same way it's going to be decoded.

The rest-client counterpart to this is cloudify-cosmo/cloudify-common#557


Reconsider hosted webapp

Just to move this discussion that we were having via email to somewhere public:
We discussed maybe going back to the hosted webapp (in addition to, or instead of, the current OpenRefine-like installed jar scheme). Since we're going to be using operators instead of computer vision for line detection, we may be able to get efficiency gains such that using a server would be feasible. Something to think about.

A self-described Chromebook power user says he can't use Tabula, since he can't install stuff on the Chromebook. Chromebook users could use the hosted version, I suppose. (Although this is a pretty small use case...)

Hi guys, whats the status of this? We have a few non technical people we want to give Tabula to. Can we just take Tabula as it exists, put it on a server behind a nginx+basic auth and be done with it?

@shabda It's totally possible to run your own hosted Tabula instance. I can't speak to the exact tools you describe, but it should work in theory. (We have a hosted version running at my workplace, with minimal modification.)
Only thing you may need to keep in mind is that you'll periodically need to remove old processed files, or it'll start eating up disk space.

@shabda: You may want to check out the https://github.com/tabulapdf/tabula/tree/feature/relative_path branch if you need to run Tabula under a subpath (e.g. example.com/tabula/). Under a subdomain (tabula.example.com) should work fine as is.


Add the ability to Update an IP Access rule

Unsure if this falls within the scope of this project, but I have a feature request:

Whenever the IP updates, in addition to updating the DNS record, add or update an IP access rule (Security>WAF>Tools) to allow the new IP.

Here are the relevant docs: https://developers.cloudflare.com/api/operations/ip-access-rules-for-a-zone-list-ip-access-rules. It seems CF does not allow the value to be edited (only mode and notes), so upon an IP change the old one would have to be deleted and a new rule with the new IP would be created. For deletion, the API supports filtering the GET results using several optional parameters, including the notes.
Let me know if I can help out in implementing this is any way.

Thanks for the suggestion. I have to admit I'm pretty ignorant about this part of Cloudflare API, and it does seem to be quite tricky. My immediate question is, is there a reliable way to indicate which rule(s) to delete without the invariant we are assuming between the notes on the Cloudflare server and the updater configuration? What could be helpful is that, if you have a working automatic system set up, I would like to learn how it's working now. I also have to admit that I couldn't devote enough time in this project before summer 2024 to implement interesting new features; even #632 is taking me too long 😟

My immediate question is, is there a reliable way to indicate which rule(s) to delete without the invariant we are assuming between the notes on the Cloudflare server and the updater configuration?

The notes parameter can be set to an arbitrary string (say This rule was created by cloudflare-ddns on $timestamp) when creating the rule. The work flow may look like:

GET request to CF with the filters object (Unsure how it is actually implemented; based on their example, a filter with the notes string set to  This rule was created by cloudflare-ddns on should return any rules with the above example string; alternatively store and append a UUID to the notes string and filter by that, the docs show a similar filter as an example). A successful request will return matching rules along with their unique identifier.
DELETE request to CF, passing the unique identifier returned above (Only one rule should be returned ideally since we delete the old one every time it updates, but maybe store results returned matching id: "*" and send a DELETE request for each)
POST request to CF, creating a new rule, passing the new IP, setting it to allow, and of course, the notes for future filtering.

I don't have an automation setup yet, I found the need for it just before I opened this issue. I'll work on it and post the code here whenever I make it.

@WolfRamAlpha12 I still feel the idea to assign meaning to supposedly unstructured notes is not very reliable. But if we put that aside, could you possibly explain why PATCH would not work?

@WolfRamAlpha12 Never mind. I saw the strange documentation that described what you said.

meaning to supposedly totally unstructured notes is not very reliable.

Appending and filtering a UUID would ensure no false positives. Storing the previously set IP and filtering by that is possible as well, so a query with configuration.target = ip configuration.value = $previousip mode=whitelist match = all would return all rules with an IP of $previousip set to allow

@WolfRamAlpha12 I prefer not to relying on stateful checks because they are fragile. Consider these cases:

Some people use external cron to manage the scheduling so the program immediately exits after the IPs are updated.
You might also want to restart or even recreate the updater container during upgrades and reboots.
A Cloudflare API call can fail for many reasons, including timeout or temporary network outage. When that happens, you cannot reliably know whether the rule has been successfully updated. (That is, you might see that the API call fails, but the change might have been made on the Cloudflare server.)
While this shouldn't happen, maybe the rules could be updated or changed by other programs or you manually.

The current stateless design is robust partly because it will eventually fix any inconsistency itself even if all of the above happen. That is, its eventual correctness does not depend on the correctness of the local state. This is the level of robustness I would like to maintain, and it's still a bit difficult for me to see how to achieve that using the current API, but maybe you could help me see it.

@WolfRamAlpha12 Just to clarify, I'm still happy to find a good approach with you and I thank you for the GitHub issue ❤

@favonia Thank you, appreciate your willingness to work with me here. I'll keep the above scenarios in mind while trying to make my automation and see if I can come up with something that can meet the current level of robustness.

Hi guys.
I believe this feature is also what I am looking for.  Whilst this tool seems amazing at doing the DDNS bit, its hard to use the outcome in a meaningful way within the cloudflare eco-system.  I think the answer is 'lists'.  You can create a WAF rule based on the contents of a cloudflare list.  So if this tool updates an arbitrary lists content, as well as the actual A record, you now have a very powerful tool to both update the record AND make it useable within cloudflares own WAF rules to do whatever you want.
Manage Account --> Configurations --> Lists
https://developers.cloudflare.com/waf/tools/lists/custom-lists/
If it were me, I would have the tool create and manage its own list (like "cloudflare-ddns") and whenever the IP address gets change/updated, delete all items in the list and create one single item that represents the current IP.  This is a 'reserved' list that can be used in WAF rules if the user wants to, or simply ignored if users don't need that.

@jdvuyk Thank you for providing the technical bits! I guess we can blame the users if they dare touch a list named ips-reported-by-cloudflare-ddns? Now I can better see how these can be made to work! Should we have one list for IPv4 and another for IPv6. @WolfRamAlpha12

Now the shoutrrr support is done, I'm back on track to implement this exciting feature :star_struck:
@jdvuyk I need your feedback about whether we should have separate lists. The free plan seems to allow only one list, so maybe I should put both the IPv4 and IPv6 addresses in the same list? Would that work well in your scenario?
Also, is this a good environment variable name to enable this feature
IP_LIST_ID=the-id-of-the-list

@WolfRamAlpha12 I was checking the details of the Cloudflare Lists and I wonder if you are fine with its limitations on IPv6 addresses, that you can only block/allow the range your-ipv6-ip/64? It seems only individual rules can have single IPv6 addresses. On the other hand, Cloudflare suggests that blocking/allowing a single IPv6 IP makes less sense (and thus the limitation).

I don't think I'll be using any IPv6 functionality, so I'm good either way. IPv6 adoption is fairly limited in my experience, don't think my ISP even assigns me an IPv6 address

Alright! I guess you don't care whether I put IPv4 and IPv6 addresses in the same list then 😆

@WolfRamAlpha12 When DELETE_ON_STOP=1, do you want the IP list to be deleted as well when the program exits? Actually, what would happen when a rule refers to a non-existing list? :thinking:

In my head deleting the list would be expected behavior if DELETE_ON_STOP=1. Unsure what would happen, might be worth testing, or just warning users of potential issues if they use both together

I seem to be getting "This list is referenced by at least one ruleset rule (Code: 10041)", so Cloudflare has prevented dangling references. :-)

@WolfRamAlpha12 Another design question (sorry!): suppose your IP list has both IPv4 and IPv6 addresses/ranges, and you ask the updater to handle only IPv4. Do you want the updater to keep the existing IPv6 addresses intact?

(PS: I'm leaning towards keeping any addresses not "managed" by the updater, but I'm curious about what you think.)

Yet another design question that is perhaps more important. I'm struggling with coming up with good environmental variable name to configure this feature:

WAF_LISTS: the comma-separated names of the lists the updater should manage
WAF_LIST_DESCRIPTION: the description for newly created lists
WAF_LIST_COMMENT_SELECTOR: the planned, advanced feature to update only the addresses with a specific comment and leave other addresses alone

Any suggestions or opinions about the names? Is WAF clear to you? We will be stuck with whatever names we choose once the feature matures due to backward compatibility.

@WolfRamAlpha12 @jdvuyk Hi, I just want you to know that, the feature to update WAF lists has been implemented, and after implementing the Happy Eyeballs algorithm for something unrelated (see #883), 1.14.0 will be released. Once 1.14.0 released, I will be much more reluctant to change the interface due to backward compatibility. Let me know if you want more time to test it, or I will ship it very soon!
To test the development version, use the edge Docker tag. The README has been updated with this new feature.


Streak Not Showing even after self hosting

Describe the bug
Streak is not showing. i have hosted my own instance on vercel, still its not working
To Reproduce
Steps to reproduce the behavior:
Go to Github.com
Click on account which had added Github streak option
Scroll down to Github streak
See error
Screenshots

**Desktop
OS: Window
Browser: chrome
Version [e.g. 22]
Smartphone :
Device: Realme
OS: Window
Browser: Chrome
Version [e.g. 22]

You have a typo in the url, try using
https://github-readme-streak-stats-topaz-six.vercel.app/?user=shinsusenju
instead of
https://https//github-readme-streak-stats-topaz-six.vercel.app/?user=shinsusenju

Thanks


When using Device message type with multiple recipients no recipient is selected

Was randomly getting 400 response from FCM API while sending push notifications. phpFCM Client silently skips adding any recipient when there's more than one available in Message.
Expected behavior should be selecting the first recipient by default or throw an exception which will explain that there's no possibility to send to multiple recipients with Device type.

Confirmed.
Message will now throw an InvalidArgumentException, when trying to add a 2nd device-type recipient. Solves the problem you had?

This should allow others efficiently catch the problem early! Thanks for your library guys.


wrong behaviour with 2-char directory prefixes

A bug discovered and fixed by @lealanko in PR #265.
Here's how to reproduce:
$ mkdir ab
$ touch ab/foo
$ attic init /tmp/attic
$ attic create /tmp/attic::1 ab/
$ attic list /tmp/attic::1
drwxrwxr-x tw     tw            0 Apr 04 10:58 ab
-rw-rw-r-- tw     tw            0 Apr 04 10:58 foo
(attic-env)tw@tux:~/w/attic$ mkdir ex
(attic-env)tw@tux:~/w/attic$ cd ex
(attic-env)tw@tux:~/w/attic/ex$ attic extract /tmp/attic::1
(attic-env)tw@tux:~/w/attic/ex$ ls -lR
.:
total 4
drwxrwxr-x 2 tw tw 4096 Apr  4 10:58 ab
-rw-rw-r-- 1 tw tw    0 Apr  4 10:58 foo

./ab:
total 0

You see, file "foo" ends up on the same level as directory "ab", NOT inside directory "ab".

I independently came across this problem last week and made my own fix before noticing this issue existed with a pull request. My fix is at https://github.com/camh-/attic/tree/fix-make_path_safe. Please consider this for two reasons:

I've used a raw string for the regex. Always use raw strings for regexes, otherwise some backslashes need to be escaped, and others don't.
I've added test cases that fail without the fix in. Test-first, and all that.

Let me know if you want it and I'll create the pull request.


server-side usage

would be nice to see server-side examples of usage... in that rendering from one user in one language won't clobber the rendering for another user in another language... there's no examples that create a separate rendering instance for a given locale.

would be nice to see server-side examples of usage

Server-side usage is a good point, it's on my list! :)

in that rendering from one user in one language won't clobber the rendering for another user in another language... there's no examples that create a separate rendering instance for a given locale.

Node is single threaded so just using x18n.set, to change the language everytime you want to render the page for a new user, wouldn't be a problem.
The set method is also really lightweight (it only changes how t will retrieve translations, but it won't actually copy any translation sets or stuff like that), so there's also nothing to worry about from a performance standpoint.

But depending on how you are using server-side rendering, that would require several changes to the focus to "set" ...  Would be better if one could have a rendering .t instance that's set to a specific language, so that it can be passed in context (think react modules) to children via the context.
Without that, one would have to call .set(context.locale) everywhere you use a template, which would severely inhibit the value this module provides.

I'm not quite convinced yet, can give you give an example of a node setup, e.g. a template system, where I can pass x18n into and it's not copied by reference?
If you require x18n several times, then you'll always get a reference to the same object. So if you set the language once, it's changed everywhere.
It's the same if you pass x18n with React props. You wouldn't really need to do that though, you could just require x18n in every React component that needs it, or just use react-x18n which also helps you with other things regarding React.


[r] Set default create options during TileDBCreateOptions$new()

Set default creation options during TileDBCreateOptions$initialize() instead of on-the-fly in the accessors. This allows easy serialization of TileDBCreateOptions with TileDBCreateOptions$to_list()
Also add a new build_filters parameter to TileDBCreateOptions$to_list(); if TRUE, builds filters with tiledb::tiledb_filter(), otherwise leaves as characters/lists of characters describing the filters
Also simplify a lot of the accessors/filter building methods, and move $.dim(), $.attr(), $.build_filters(), and $.build_filter() to be private methods instead of public ones

[sc-48524]


Fix Booking Order Validation

Coverage decreased (-0.02%) to 77.174% when pulling 064ad8aa56680abdabbfa01210f2a7efc936a98e on kharissuryandaru:dev into 3bd9f88037002d431a5a07e766c15a5ea3567cbf on danliris:dev.


zsh: ensure history path directory exists

Fixes #886.

Getting error: string 'some/directory/zsh_history' doesn't represent an absolute path, at /home/travis/build/rycee/home-manager/modules/programs/zsh.nix:304:20.
It seems like nix version used by travis (2.0.4) is too old for this feature: https://github.com/NixOS/nix/pull/2349. See also https://nixos.org/nix/manual/#ssec-relnotes-2.2.
@rycee should I fix the patch, or should we switch to a newer version of nix on travis?

I guess I can go for another solution which is creating a directory from zsh scripts. And should probably finally fix this issue too: https://github.com/rycee/home-manager/pull/427.

I rewrote PR both to address the original issue and to fix long longstanding issue with the history.path behavior, see #427.
@teto can you double-check that this PR solves your use case? I know you were waiting for this fix for a long time :)
This PR depends on https://github.com/rycee/home-manager/pull/892 being merged too.

Nice! Rebased to master in<PHONE_NUMBER>52c9311fcb2894328696b535265593. I included an update to the version 20.03 release notes.


Generate sdk for latest branch with latest changes from azure rest-specs-api

stable branch of  autorest.go and stable branch of specs

to decide

PR for each spec change or nightly
automatic merge into nightly branch or not ( to begin with )  (correlates with the first point)

For latest branch let's start with a 24 hour cadence.  Set up a cron job to sync latest specs, generate SDK and profiles, validate, and commit.  Note that as part of this automation we must include the commit hash of the specs repo and the generator version.

This has been superseded by the swagger->sdk work.


Guard sigil

We have @ and - sigils which control linewise recipe execution. I thought that we could consider having a "guard" sigil which indicates that an error on a particular line should terminate the execution of the current recipe, but not the whole run.
For example, to make a recipe only execute if the environment variable FOO is set to yes:
foo:
  ?[[ $FOO == yes]]
  # the rest of the recipe

This is backwards incompatible, so would need a setting to opt-in to the new behavior. (Although it's unlikely to break most justfile, ? at the beginning of the line is unlikely in sh and derivatives, and I think most scripting languages that people are likely to use.)

A further enhancement that would be nice is a way for the condition to be evaluated without invoking the shell e.g.:
foo:
  ?{{ assert(foo == 'yes') }}
  # the rest of the recipe

@liquidaty There would have to be a different syntax for this, since I believe the pattern of having an interpolation first is common.
For example, if someone wanted to use Python to perform a test, they might do:
python := '/usr/bin/python3'

foo:
  ?{{ python }} …

There would have to be a different syntax for this

Got it. Any syntax would be fine by me, but as I'm a new just user, that doesn't count for much.
That said, if it can be done, then, it seems logical (to me at least) to allow {{ assert(...) }} inside the recipe (and if it wasn't allowed before, it wouldn't seem to cause any compatibility issues to allow it). Currently, I can do this outside of a recipe:
a := if b == c { ... } else { ... }
d := assert(...)

and I can do this inside a recipe:
    {{ if b == c { ... } else { ... } }}

So it seemed logical to me that anything to the right of := outside a recipe, could also be put inside {{ }} inside a recipe, and that therefore this would also work inside a recipe:
    {{ assert(...) }}

Though I guess maybe the issue is that assert raises an error or returns a different data type than a shell command's exit code.


NUTCH-3002 Protocol-okhttp HttpResponse: HTTP header metadata lookup should be case-insensitive

implement class CaseInsensitiveMetadata providing case-insensitive metadata look-ups (but no spell-checking)
use CaseInsensitiveMetadata to hold HTTP header metadata in in the class OkHttpResponse of protocol-okhttp
add unit tests to prove the fix (and also case-insensitive look-ups and spell-checking in protocol-http)

The unit tests also include a deactivated benchmark: storing HTTP headers in CaseInsensitiveMetadata is approx. 10% faster than in SpellCheckedMetadata.

since you asked me to have a look at it @sebastian-nagel, it looks good to me!


PubSub - 1.116.3 crashes JVM on JDK/JRE 17 docker image openjdk:17-jdk-alpine

Hello
I'm trying to use this new version, but my application didn't start. and I got this error :
A fatal error has been detected by the Java Runtime Environment:                                                                                │ │ #                                                                                │ │ #  SIGSEGV (0xb) at pc=0x0000000000003fd6, pid=27, tid=37                                                                                │ │ #                                                                                │ │ # JRE version: OpenJDK Runtime Environment (17.0+14) (build 17-ea+14)                                                                                │ │ # Java VM: OpenJDK 64-Bit Server VM (17-ea+14, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, serial gc, linux-amd64)                                                                                │ │ # Problematic frame:                                                                                │ │ # C  0x0000000000003fd6                                                                                │ │ #                                                                                │ │ # Core dump will be written. Default location: /core.%e.27.%t                                                                                │ │ #                                                                                │ │ # An error report file with more information is saved as:                                                                                │ │ # /src/hs_err_pid27.log
docker image
FROM openjdk:17-jdk-alpine as BUILD ARG NEXUS_USERNAME ARG NEXUS_PASSWORD COPY . /src WORKDIR /src RUN ./gradlew clean installDist
gradle dependency
 implementation("com.google.cloud:google-cloud-pubsub:1.116.3")

1.116.4 same error

This looks like a duplicate of #947.


Connection error causes system.exit

If any exception other than Timeout or TooManyRedirects is encountered, the default behavior is to log the exception and then invoke sys.exit(1) and terminate.
I have observed the following error logged before terminating:

2019-05-03 04:04:49,777 newrelic_marklogic_plugin.http_utils ERROR    ('Connection aborted.', BadStatusLine("''",))

Rather than terminating, the desired behavior for these unsuccessful requests would have been to log the error and then simply retry after the configured seep duration.
Consider changing http_utils.py to expand the list of request exceptions that can be handled without killing the application.


feat(rds): Finish RDS module

Goal
Create RDS module that also creates a secrets manager resource for the RDS credentials.
Have you followed the guidelines in our Contributing document?
Yes/Hope so
Implementation Decisions
For this version, I opted not to create a secret rotation lambda because I ran into issues with getting information about the secret from secretsmanager. I created a VPC endpoint for secretsmanager but that still didn't allow access. In the interest of moving forward and using this module in some newer repositories, the described issue with secrets rotation will be handled in a later version.

:tada: This PR is included in version 1.14.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Bug] Popup is crashing if the Size property is set on Nexus 4, Lollipop 5.0, api 21

Description
The title says everything. The Popup view, if has Size property set, is crashing with an:
System.InvalidCastException
Message=Specified cast is not valid.
XCT version 1.2.0-pre2

The title says everything.

Actually it doesn't :)
There is much more info in the bug report template that would be really helpful to is. In the very least: what is the code/XAML you are using that causes this error?
Please update the issue with as much detail as possible and do so for next issues you open. The info in there might look trivial to you, but it is in there for a reason.
Thanks

I think this is a duplicate of #1193


Text wrapping not working

Describe the bug
Text wrapping does not work correctly in ScrollViewer, when the text is written in several languages.
Property TextWrapping="Wrap" in TextBlock of the ScrollViewer component.
To Reproduce
Steps to reproduce the behavior:
          <ScrollViewer
		AllowAutoHide="False"
                HorizontalScrollBarVisibility="Disabled"
                VerticalScrollBarVisibility="Auto">
                <TextBlock
                      FontSize="16"
                      Text="{Binding SelectedItem.Description}"
                      TextWrapping="Wrap" />
           </ScrollViewer>

Where SelectedItem.Description contains text on russian and english languages.
See error on screenshot.
And there are non-breaking spaces (alt+255) in the text, and in this case they also do not work.
Expected behavior
The hyphenation should be by words, not by letters.
Screenshots

Desktop (please complete the following information):

OS: Windows 11 21H2
Version Avalonia: 0.10.16

@nekdan can you maybe try the same text with latest prerelease or in ControlCatalog? There were many text processing improvements recently for v11.0.
Hint: Don't update in your App as there are some breaking changes in current master.
How to get prerelease: https://github.com/AvaloniaUI/Avalonia/wiki/Using-nightly-build-feed

I think this is fixed in nightly build.

Closing as fixed in nightly


left, I return nil, and the left will appear a blank.

The first, drag to left, the right actions will appear.
The second, drag to right and the left will appear blank
The third, when I stop drag, it will reset with an animation. But I tap the cell, the animation stop before completion. So that the left remain a blank.

What version of SwipeCellKit are you using?

Your demo, you should return nil when orientation == .left.

pod 'SwipeCellKit', '~> 2.2.0', the bug can't reset perfectly ----> only  orientation = .left or .right

Please upgrade to latest version, I don't think is occurs in v2.4.2

Now, I use 2.4.2，it is the same bug.  Please close left, and use iPhone(my iPhone is 8 Plus), try to use two hands as far as possible, and the bug will appear.
------------------ Original ------------------
From: "Mohammad Kurabi";
Date: 2018年6月14日(星期四) 下午2:37
To: "SwipeCellKit/SwipeCellKit";
Cc: "yidai"; "Author";
Subject: Re: [SwipeCellKit/SwipeCellKit] left, I return nil, and the left willappear a blank. (#215)
Closed #215.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

This is your demo, use 2.4.2 (pod installed)
SwipeCellKit-2.4.2.zip
this is bug

What iOS version are you on? I tried to reproduce this but I can't. I tried on device too iOS 11.
If you are on iOS 11, please do a screen recording in case I am not understanding how you are running into this issue.

Ok I see the issue now. Not easy to reproduce.

Please look at the fix in develop branch and let me know if it addresses the issue. Will release this after some testing.

OK， I use the develop branch version,  .ended, .cancelled, .failed to reset .  It is beautiful, when do you publish the new release version?
------------------ Original ------------------
From: "Mohammad Kurabi";
Date: 2018年6月15日(星期五) 中午1:34
To: "SwipeCellKit/SwipeCellKit";
Cc: "yidai"; "Manual";
Subject: Re: [SwipeCellKit/SwipeCellKit] left, I return nil, and the left willappear a blank. (#215)
Please look at the fix in develop branch and let me know if it addresses the issue. Will release this after some testing.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

And thanks to support !  I find that you modified a lot of code.

Yep. That’s why it needs a good testing period before release.


Private CA certificates / OAuth login

I am just trying out JiraOne to see if I can use it, connecting to a Jira Datacenter air-gapped installation for a client, and they have their own CA with certificates signed by that CA, but which JiraOne considers as self-signed and refuses to go further.  Thus I’m stuck at the first step.  I’ve had a look at the documentation, but can see no mention of certificates.
I’ve also followed Atlassian’s instructions to create an Application Link (generating an RSA key pair and supplying the key to Jira to create the application link) to use OAuth 1.0a, but don’t see how to use it with JiraOne or if it is possible.
I’d be grateful if you could advise me at all?  Many thanks :-)

Hey @69baud
OAuth 1.0a isn't supported, only OAuth 2.0 and it's for cloud platforms. If you want to connect to Jira DC and use a self-signed CA. You can use the argument verify=False on any of the HTTP requests or you can use the path to the self-signed CA and make the request persistent.
# previous login statement
LOGIN.session.verify = "/path/to/certfile"
# OR
LOGIN.session.verify = False

Using the false value, jiraone won't validate the SSL certificate during connection. Let me know if that helps.

Thanks. I was following an Atlassian document on OAuth for Data Center.  I guess it is out of date.
I've tried both options and it still complains about the SSL Self-Signed Cert.  I ran the debugger and can't see where in JiraOne it actually passes session.verify (or cert_file) anywhere to requests.post or requests.get etc
I've also tried setting environment variables such as SSL_CERT_FILE pointing to the Root CA and Intermediate CA bundle (file in pem format) but still no joy.
Any other ideas?
Thanks :-)

Here are the two options:

I would suggest forking this repo and adding the HTTP methods you need with the option verify=False for each HTTP request. As jiraone has the ability to accept that option as a keyword argument. Basically, jiraone's HTTP request ability is the same object as the requests library. However, this is not recommended but if you're on a secured network and know what you're doing then you can attempt it.
A typical request e.g.

# previous login statement
LOGIN.get(endpoint.myself(), verify=False)
# OR
LOGIN.post(endpoint.jira_group(), verify=False)

OR

If you're still getting the cert error and want to verify the cert. You can know how the cert requests use and what it is like.

import requests
import os
cert = requests.certs.where()
# The above should tell you where's the CA pem requests uses
# since this is self-signed probably the chain might be incomplete
# I would suggest verifying if the chain is completed before doing below
your_cert_path = "direct_absolute_path/to/cert"
os.environ["REQUESTS_CA_BUNDLE"] = your_cert_path
# before calling jiraone statements

Let me know how it goes.

Thanks you :-)
your_cert_path = "direct_absolute_path/to/cert"
os.environ["REQUESTS_CA_BUNDLE"] = your_cert_path
Fixed it 👍


[feature] #2794: Reject Fieldless enums with explicit discriminants in FFI

Signed-off-by: Shanin Roman<EMAIL_ADDRESS>

Description of the Change
Derive macro FfiType now rejects fieldless enums with explicit discriminants.

Issue
Closes #2794.

Benefits
Less space to make errors.

Possible Drawbacks
None.

I think you can also simiplify the variant_discriminants function


Add support for multiple mbtiles

Add support for multiple mbtiles files through urls_mbtiles. This is only my little hack in order to support mutltiple mbtiles not only one as a data source. If this is not appropriate and you also want to add this feature I can modify it as you will want.

Reply to comment https://github.com/tangrams/tangram-es/pull/2119#issuecomment-566767128 example of using this parameter is (on Android platform):
source:
mapzen:
urls_mbtiles: ["/storage/emulated/0/offline_maps/belgium.mbtiles", "/storage/emulated/0/offline_maps/netherlands.mbtiles", "/storage/emulated/0/offline_maps/germany.mbtiles"]
in my app I allow users to download map data stored in mbtiles format. They can download mbtiles for every country in the world. Firstly I have tried after downloading mbtiles to merge them into one mbtiles file on Android device and it was very very slow - counts in minutes. Then I added support for using mutltiple mbtiles and when trying to show a tile, check which mbtiles file contains this tile and use it from that mbtiles file.
I just needed this functionality and thought that it could be useful also for other developers which want to use Tangram-ES for offline maps stored in mbtiles.

Aha, thanks for sharing your use case! So this data source is a set of local archives that can be used offline. This does seem like a reasonable scenario for us to support. I'll take a look at the changes and see how we can best enable this.

Ok, I have tried to address your requests and also done some additional cleanup and fixes.

I am concerned about name of actual YAML paramter name of urls_mbtiles if this is correct, or if it should be somehow done together withing url parameter.

@rwrx I've been thinking about that as well - specifically whether we should have a different way of configuring these kinds of "offline archive" data sources, since they need to behave somewhat differently than "online" tile sources. Might try out some ideas this weekend but I'll be traveling for holidays soon so apologies if I'm slow to respond!

@matteblair I was thinking about extending url parameter to accept array of urls, but I wasn't sure if it will be consistent semantically, so I rather created new parameter.


Provision dialogs tells me there are no applications when there are

I have a deployment config in my project, but the dialog tells me there are no applications to bind.

I've also noticed that the placeholder is wrong even when there are applications when creating a binding from the console overview.

cc @jwforres


Inline values being used instead of templates

Inline values prevent templates from being checked as individual files externally, but this is only a nuisance. The real danger is that forgetting to close an inline delimiter changes semantics of the entire .tf file. Check the example below:
module "a" {
  source = "some-path"
  param = <<EOF
bar
EOT
}

module "b" {
  source = "some-path"
  param = <<EOF
baz
EOF
}

The following code above will terraform apply correctly, but module.a.param will not be bar, and module.b will never be created. In modules with nested resources or a large amount of modules this can easily pass unnoticed — specially common since modules take no count.
A counter-argument is that syntax highlight could potentially showcase this problem. But this cannot be checked without human intervention, as a checker cannot know if module.b should or not be created.
The following modules are currently using inline values and should be changed to use templates with external files instead:
examples/nexus-asg/nexus.tf
58:  init_prefix = <<END_INIT
64:  init_suffix = <<END_INIT

examples/cloud-dev-workspace/main.tf
93:  user_data = <<END_INIT

examples/vpc-scenario-1/main.tf
91:  user_data = <<END_INIT

examples/kube-stack-private/bastion.tf
50:  user_data = <<END_INIT

examples/kube-stack-public/bastion.tf
47:  user_data = <<END_INIT

examples/gitlab-asg/main.tf
158:  init_prefix = <<END_INIT
164:  init_suffix = <<END_INIT

examples/legacy/main.tf
43:    extra_init = <<EOF
139:    extra_init = <<EOF

examples/vpc-scenario-2-nat-instances-per-az/main.tf
245:  user_data = <<END_INIT

examples/vpc-scenario-2/main.tf
149:  user_data = <<END_INIT

modules/elk-stack/main.tf
141:  extra_config = <<END_CONFIG

modules/init-snippet-gitlab-docker/main.tf
77:  template = <<EOC
91:  template = <<END_INIT

modules/snapshot-bucket/main.tf
22:  policy = <<EOF

examples/vpc-scenario-2-nat-instance/main.tf
241:  user_data = <<END_INIT

modules/dnsmasq-server/main.tf
21: *       template = <<END_CONF
53: *       user_data = <<END_INIT

modules/kibana/variables.tf
62:  description = <<DOC

modules/kube-stack/main.tf
70:  user_data = <<END_INIT
108:  user_data = <<END_INIT

modules/kibana/main.tf
128:  user_data = <<USER_DATA

modules/persistent-ebs-volumes/iam.tf
9:  policy = <<END_POLICY

modules/persistent-ebs/iam.tf
11:  assume_role_policy = <<END_POLICY
33:  policy = <<END_POLICY

modules/scale-asg-iam-policy/main.tf
13:  policy = <<EOF

modules/elasticsearch/data-nodes.tf
102:    extra_setup_snippet = <<EXTRA_SETUP
133:    extra_config       = <<EXTRA_CONFIG

modules/elasticsearch/variables.tf
133:  description = <<DOC
158:  description = <<DOC

modules/elasticsearch/iam.tf
39:  assume_role_policy = <<END_POLICY
60:  assume_role_policy = <<END_POLICY
80:  policy = <<END_POLICY

modules/single-node-asg/main.tf
52:  user_data = <<END_INIT

modules/logstash/iam.tf
44:  assume_role_policy = <<END_POLICY

modules/consul-demo-server/main.tf
32:  init_suffix = <<END_INIT

modules/elasticsearch/master-nodes.tf
103:    extra_setup_snippet = <<EXTRA_SETUP
131:    extra_config = <<EXTRA_CONFIG

modules/prometheus-server/main.tf
44:  user_data = <<END_INIT
68:  init_prefix = <<END_INIT
75:  prometheus_pillar = <<END_PILLAR

modules/ec2-nat-instances/main.tf
32:  init   = <<END_INIT
52:  template = <<END_INIT

modules/credstash-setup/data.tf
14:  template = <<END_TEMPLATE

modules/consul-agent-generic-init/main.tf
32: *     extra_init = <<EOF

modules/ebs-snapshot-iam/main.tf
43:  policy = <<EOF

modules/prometheus-server/tests/main.tf
73:  init_suffix = <<END_INIT

modules/credstash-setup/main.tf
56:  policy = <<END_POLICY
78:  policy = <<END_POLICY

modules/ec2-auto-recover-instances/main.tf
45: *       user_data = <<END_INIT

I would prefer to have a tool that warns us when a mistake has been made, over classifying all use of inlines as evil. I believe we should review occurrences of this individually, and I'm not sure how I feel about a single issue to encompass of occurrences of this pattern.

There is nothing inherently evil in this, just as there is nothing evil in pointer arithmetic in C. But designing a tool that checks when either is correct is a very large challenge. It’s just a set of tradeoffs.
I will remove the checks from #103 until we do a manual review then.
We can add the review for the items above in this issue here until all occurrences have been documented as OK or not, since it has to be tracked somewhere and this has the list already. Then we close it. Sounds good?


Question: how to implement passthrough attrs?

Hi,
I have this setup:
widget/base.html
<c-vars field show_label autocomplete="off" extra_class="" container_extra_class="" />

<div>
    ...
    <input ... {{attrs}} />
    ...
</div>

display.html
<c-vars field show_label autocomplete="off" extra_class="" container_extra_class="" />

<c-widget.base
    :field=field
    class="w-full {{extra_class}}" />

How do I pass c-display attrs object to c-widget.base?
In 0.9.40 nothing happens with :attrs=attrs. In later versions seems to add some sort of a wrapper that renders to attrs = "class="w-full " with this odd syntax with unclosed double quote.

The idea is that I wanted to retain both attrs as I pass them into some template tags. I guess I expected them to merge. 🤷
In the end, I used attrs from base and passed parent attrs to base through :extra_attrs=attrs. Did the trick {{ field|append_attr:extra_attrs|append_attr:attrs }} 🤞
Hard to say now what I was doing wrong, this was a small part of cleaning up very convoluted codebase.


Reshape bias to 1D for cpufusion of conv+bias bprop

Sorry for that. Done

@nbpatel Could you please merge my branch https://github.com/NervanaSystems/ngraph/tree/louisfeng/convbias-shape_check into yours for this PR? It includes some validation code that should help us catch these errors sooner. Thanks.

TESTNOW


Unable to access extended properties in constructor

I'm not sure if this is an intention of typescript or not but acts differently to how I would've expected.
If i have a base class and extend it, overriding some base class properties, then want to work with the properties in the child class constructor I still access the parent properties.
This is shown in the below basic example.
class Base {

    public myVar:string = 'Base';

    public constructor() {
        console.log(this.myVar);
    }

}

class Child extends Base {

    public myVar:string = 'Child';

}

var base:Base = new Base(); // 'Base' - As expected
var child:Child = new Child(); // 'Base' - I would've expected this to be 'Child'

console.log(base.myVar); // 'Base' - As expected
console.log(child.myVar); // 'Child' - As expected

This happens in the compiled JS because the super is called before the child properties are set:
function Child() {
    _super.apply(this, arguments);
    this.myVar = 'Child';
}

Is this intended? An issue? Or a trade off because of JS limitations? Thanks!
Note that if I do something like this, it works as I would've expected. However it feels like a bit of a hacky work around.
class Base {

    public myVar:string = 'Base';

    public constructor() {
        this.setup();
    }

    protected setup() {
        console.log(this.myVar);
    }

}

class Child extends Base {

    public myVar:string = 'Child';

    public constructor() {
        super();
        this.setup();
    }

}

var base:Base = new Base(); // 'Base'
var child:Child = new Child(); // 'Child' - Now as expected

console.log(base.myVar); // 'Base'
console.log(child.myVar); // 'Child'

This is the intended behavior.
The order of initialization is:

The base class initialized properties are initialized
The base class constructor runs
The derived class initialized properties are initialized
The derived class constructor runs

Why is this the order?
First, look closely at the JavaScript emitted for a class. There are only two places where code runs -- in the static initialization of the class (where the prototype is set up and static members are initialized), and in the constructor function for the class instance. Property initialization is injected into the first part of the constructor, which means that step 1 and step 2 are necessarily going to happen one after the other.
It's also clear that the base class constructor has to run before the derived class constructor.
This leaves us with only one alternative:

The derived class initialized properties are initialized
The base class initialized properties are initialized
The base class constructor runs
The derived class constructor runs

That ordering would result in very surprising behavior:
class Base {
    x = 'foo';
    getX() {
        return this.x;
    }
}
class Derived extends Base {
    m = this.getX(); // Would be 'undefined', not 'x'
    constructor() {
        super();
    }
}

I would expect that example to give an compile error because you would/should never use this in class variable decleraction

I think it's worth noting that the behaviour of C# is exactly as the alternative mentioned above, i.e.

The derived class initialized properties are initialized
The base class initialized properties are initialized
The base class constructor runs
The derived class constructor runs

The example given that would result in "very surprising" behaviour is prevented by the compiler:
class Base {
	public string x = "foo";
	public string getX() {
		return x;
	}
}

class Derived : Base {
    public string m = this.getX();   // CS000027 Keyword 'this' is not available in the current context
}

I suspect this is one of the reasons people keep raising this issue - programming in the style they're used to simply doesn't work in TS, and you have to use horrible workarounds to accomplish the same thing.  However, given that this was first replied to in Jan 2015, I suspect we're too far down the line for anyone to consider changing the behaviour in case it breaks existing code.

This behavior seems like an unusual issue to confront.

However, the TS declaration style requires being able to access this:

class Test {
    FirstName: string;
    Surname: string;
    FullName = () => `${this.FirstName} ${this.Surname}`;
}

Just wanted to mention this example is accessing this in the context of a function, which should still work in the alternative behaviour.

I'd like to add my vote for a solution that makes more sense to OOP veterans coming from other languages, whether it is for EcmaScript or TypeScript only.  I wrote an article on the subject, including suggested workarounds.

To execute the Base constructor after Derived class values have been set I am including Base constructor's operations in a setTimeout function. Everything seems to work ok but I don't know what other implications this might have. Anyone with more knowledge can comment if this is a bad practice and why?
class Base {
    x = 'foo';
    constructor(){
       setTimeout(()=>{alert(x)},0); //Alerts 'bar'
    }
}
class Derived extends Base {
    x='bar';
    constructor() {
        super();
    }
}

Sorry for my question.
But, still, it is a bug or a feature?

Its just the way TypeScript works

It is rather, how JavaScript (ES6) works.

This makes no sense what so ever in my view.
JS is prototypal. The object oriented community found it weird and came up with loads of hacks to simulate class based inheritance. In doing so there became lots of gotchas such as accidentally forgetting the "new" keyword, which in turn created more hacks. The JS comity finally decided to support the vast number of object oriented users of JS by adding in class support. However, they decided they didn't like being pressured into adding "normal" class based inheritance that most people would instantly understand (and assume) and so decided to follow the somewhat normal JS way of doing the occasional "wtf" implementation to trip up users ( https://martin-thoma.com/javascript-wtf/ https://www.smashingmagazine.com/2011/05/10-oddities-and-secrets-about-javascript/ http://charlieharvey.org.uk/page/javascript_the_weird_parts to name a few). Implementing sub class constructors in a way that most of the object oriented community will trip up on I guess is at least sticking with the core of the JS craziness! Shame though that TypeScript still follows that philosophy when it has so much of everything else right (in my opinion).

They're going to be really disappointed when ES6 class property initializers have the exact same semantics.

@RyanCavanaugh @mhegazy I'm not sure what you guys are talking about, because ES6 doesn't even support proper class property initialisers. It requires you to set the object instance properties in the constructor just like ES5.
So how can you say "that's just how ES6 works" or "ES6 will have the same semantics" if the whole notion of class property initialisers doesn't even exist in the latest ES8 draft?
Since TypeScript is emulating class property initialisers, it should do so in a way that we would expect ES9 to maybe implement them, or at least implement it the way it's implemented in just about any other OOP language, since those are what TypeScript is basing this language feature on in the first place.
You can't use the way ES6 does object property initialisation as an excuse to just break a separate language feature.
For me it shows that whoever implemented class property initialisers in TypeScript doesn't really grasp the difference between setting properties in the object instance or having them inherited and initialised from a child class.
It's just plain incorrect from an OOP standpoint.
When setting properties from the constructor, you already have an object instance of a class. You're working with that instance and what class it was doesn't really matter anymore, because the class was only used as a template for the object instance.
When instantiating a class that extends another class (new Child()), you're expecting the object instance to be based on the complete flattened "template" of the class you're instantiating, including class property initialisers.
By the time you're in the context of the object's constructor, you're already working with the object, which should be based on the class you instantiated, which was Child and not Base. So why are you getting Base's properties? It just doesn't make sense.

@Yogarine I added two language examples (Python & PHP) in #15247 which do things how one would expect. However, the java and .net languages tend to do the same as JS.
@RyanCavanaugh did make a good point with this crazy code being possible if JS followed the path of Python and PHP.
class Base {
    x = 'foo';
    getX() {
        return this.x;
    }
}
class Derived extends Base {
    m = this.getX(); // Would be 'undefined', not 'x'
    constructor() {
        super();
    }
}

However, given the example above. That's not a style of code I've come across and languages I've used simply wouldn't allow you to define a property the return value of a function like that. All method calls would be done in constructors and other methods. So while yes, it creates crazy code so does the alternative! My opinion is that the example used to justify the decision that was taken is far more of an edge case as opposed to how often people will be stung by the case in this and #15247 bug reports.
So, I felt that was more a mistake of JS and not one that TypeScript necessarily had to make. But, this is largely opinionated since I can understand why TypeScript would attempt to follow in the same footsteps as JS. (Though I'm saying that without being overly familiar with the ES6+ specifications so I'm unsure about that path).
The current implementation I still believe does not make any logical sense (especially around abstracts), already tripped us up, people creating workarounds and custom rules (such as new Abc().init() allowing init() to be forgotten and another source of frustration), and typescript doesn't warn us about illogical code that will always result in a bug such as that mentioned in #15247 so I believe there is still room for improvement on the current implementation even if I don't fully agree with it.
Personally, I believe the other route should have been taken (as suggested in this issue) and restrictions applied within typescript to stop crazy code such as that mentioned by Ryan. After all, isn't typescript about making JS safer? With compilation, more warnings, static type checks, etc so to me I don't believe this expectation would be unreasonable.
But I understand this is just an opinion and like @RyanCavanaugh said, they had to go with one of them. If they had gone with the suggestion in here, this thread would likely be about how they didn't follow the likes of Java or .net and how confusing TS would be for them people lol. So they couldn't win either way.
Anyway, that's it from me in here as I feel this topic is becoming a battle of perseverance in voicing opinions than being productive. People have already made up their mind.
Great discussion though 👍

@PMXScott

However, the java and .net languages tend to do the same as JS.

In what way? They do class property initialiser the same as PHP, C++ and any other OOP language I know of.

That's not a style of code I've come across and languages I've used simply wouldn't allow you to define a property the return value of a function like that.

That is because normally when class properties are defined this is done when defining the class and not the object, so you don't have an object instance (this) yet. The reason your example works in TypeScript is because, like I said, the person implementing this didn't understand the difference between class definitions and object (or JS "function") definitions.
In purely prototype-based languages like JavaScript/ES5 the only things you can work with are objects, and inheritance is done using prototypes. However now that classes get introduced to these languages JavaScript developers that are used to treating everything as objects for the first time have to deal with structures that aren't first class citizens. That's probably why ES6 doesn't support class property initialisers yet, and why the TypeScript developers got so confused as how to implement classes in TypeScript.
private m = this.getX(); in the class context works in TypeScript because of the way the class is translated to JavaScript. A non-first-class citizen (the class) is translated almost 1:1 to a JavaScript function (which is a first class citizen). If classes as an OOP concept would've been implemented properly in TypeScript, extra checks should've been added to prevent code in the class context to access the the object instance context.

@Yogarine

In what way? Java and .net do class property initialisers the same as PHP, C++ and any other OOP language I know of.

I'm not a Java or .Net developer. But I wrote out the same examples I did in PHP and Python in Java (pretty sure I did Java, did a few languages) & .Net (specifically C#) using online executors to find they both gave the same outcome as JS (though is possible those tests could have been flawed).
You won't find me disagreeing with the rest of what you wrote either 👍
It's as if the JS community are so used to the prototypal paradigm that they are trying to preserve it when moving to the class based OO paradigm and creating a strange mash up of both. Instead of fully embracing OO.

I wrote out the same examples I did in PHP and Python in Java (pretty sure I did Java, did a few languages) & .Net (specifically C#) using online executors to find they both gave the same outcome as JS

I just double checked and you're right. You can use the this context in Java and C#. It's weird, (at least for me since I'm primarily a C++ and PHP developer,) but it works as expected because they initialise the properties before they call the constructor, which is what this whole issue is all about.

Class property initializers are coming to ES6 classes at some point, and the current proposal has the same behavior as TypeScript's. This is covered at https://github.com/tc39/proposal-class-public-fields/issues/54 and https://github.com/tc39/proposal-class-public-fields/issues/15
You guys keep talking about this like we had three options:

Do the right thing
Do a weird thing where derived properties are set before base constructors run
Do a weird thing where derived properties are set after base constructors run

The first option does not exist. The first option does not exist.

the person implementing this didn't understand the difference between class definitions and object (or JS "function") definitions.

For me it shows that whoever implemented class property initialisers in TypeScript doesn't really grasp the difference between setting properties in the object instance or having them inherited and initialised from a child class.

Seriously?

You guys keep talking about this like we had three options:

Not me. Or rather, for me the right thing is just obviously point 2, since that's what's expected considering how OOP works.
From Wikipedia:

In object-oriented programming, a class is an extensible program-code-template for creating objects, providing initial values for state (member variables) and implementations of behavior (member functions or methods)

A class should be a template for the object I'm instantiating. When using inheritance, the Child class can and will override properties of the parent.
So when I instantiate a Child, when I'm in the context of the constructor, I expect to see a Child, not a Base. I expect to Child's default values for the properties.
It's so obvious it hurts.

Seriously?

I don't think he quite meant it like that @RyanCavanaugh . It's clear that you and the rest of the TypeScript team do understand it very well (seriously, you guys have made a compiler!) and a decision had to be made.
It's easy for someone who has a strong belief to develop tunnel vision on a problem and forget that the problem is in fact quite small given the bigger picture. This problem is hardly a show stopper and once people understand it, they can work with it (though you wouldn't believe it given how much effort we have all contributed here).
 Just how it is. Don't take any of this personally :)

I actually misspoke earlier, because in ES6 it's illegal for the derived class to do anything before calling super. So there is literally no other option than the one we chose.
Any further discussion should be at https://github.com/tc39/proposal-class-public-fields/issues/54 where the official ES spec for this behavior is being worked out.

@RyanCavanaugh

Class property initializers are coming to ES6 classes at some point, and the current proposal has the same behavior as TypeScript's. This is covered at tc39/proposal-class-public-fields#54 and tc39/proposal-class-public-fields#15

Thanks for linking those, I wasn't aware of those proposals or these comments.
I assume you mean "come to ES8 or ES9 classes", since the ES6/ES2015 spec was finished and published in 2015. Is it commonplace to just refer to ES6 as ES6+ or is there some spec extension thing going on that I don't know about? I might have been confused since you specifically mentioned ES6 before.
I have now read those comments and the spec proposal, and I do understand the need to be forward-compatible with any future ECMAScript standards, so in that case sticking to the spec proposals is a good Idea.
Sorry if I sounded overly harsh. I wish I had seen those links you posted sooner. From what I've read in these comments in relation to why they propose this order of how properties are set, it seems like they have a valid reason. (Also, I didn't realise classes are also first-class citizens in ES6).
I'll just rest my case and accept the response that "a future ECMAScript edition will probably work like that, so that's how we're doing it". At any rate I understand now this is not the place to fight this battle.

I just refer to non-downleveled classes (i.e. classes that are run natively) as "ES6 classes" because ES6 is the spec version that added them.

FWIW: I really like the approach Swift takes to this. Unlike ES/TS, where a call to super is required as the first thing a constructor does, you're actually required to initialize all of your own uninitialized private variables first. A child class cannot call super or any of its own methods before each of its member variables are set. This fixes a number of issues in many parts of the language, this one included, and has been the most intuitive to me.
That said, I respect TS's stance to follow ES proposals as much as possible. It appears the best place to voice an opinion is with Ecma International.

I think this example illustrates why this behavior is confusing (at least to me) better than the one above:
class Base {

    public constructor() {
        this.setup();
    }

    protected setup() {
    }
}

class Child extends Base {

    public myVar: string[] = [];

    public constructor() {
        super();
    }

    protected setup() {
        this.myVar.push('one'); // throws TypeError: Cannot read property 'push' of undefined
    }
}

var child: Child = new Child();

Tracking at https://stackoverflow.com/questions/43595943/why-are-derived-class-property-values-not-seen-in-the-base-class-constructor now


Code link correction

Hi Yi,
Thanks for making the curated paper list public.
The code for our paper Towards Robust and Adaptive Motion Forecasting: A Causal Representation Perspective is split into two repositories. In the current paper list, the code link actually corresponds to our secondary repo.
Could you please replace it with the primary repo (https://github.com/vita-epfl/causalmotion)?
Thanks,
Yuejiang

Hi Yuejiang,
Thank you for staring this paper list.  Sorry about the mistake, I just replaced the original link with the primary one. It's an excellent work, I discussed with Riccardo Cadei in New Orleans, and this inspired me a lot.
Best,
Yi

Thank you, Yi, for updating the link :)


Add board sounds

Chess board sounds for

new move
captures
check
checkmate

shall I take it? @Bot-Rakshit

Go ahead sir


BUGs ;)

I can write in the text box you've used to describe what increasing vnodes does.
Also, that window has absolutely no way to close it, one must close the app to quit that window once open.

@GeoSn0w Didn't notice the first actually...
Hmm. I can close it on an iPad by just clicking outside. I think I have to test on an iPhone

Fixed all of them :)

You also have one that gets "Jailbreaking...." stuck even after the Jailbreak is done.

@GeoSn0w Close the app and it will show "Successfuly jailbroken". Apparently I need to make it change after the jailbreak is done too (not only in viewDidLoad)

@GeoSn0w Should be challanging since the jailbreak starts at ViewController.m and ends at jailbreak.m. I would need to find a way to modify the jailbreak button image, which is linked to ViewController.m, via jailbreak.m

Not really, you can do it differently, I'll push a pull request if you want.

@GeoSn0w Nvm I think I can do it


Tweak linting

Description
Update linting

sync pre-commit / tox flake8 configuration
add experimental informative only interrogate support

References
Fix #593
Checklist

[x] I have read the contribution guide
[x] Code lint checked via inv lint
[x] changes file included (see docs)
[x] Usage documentation added in case of new features
[x] Tests added

Coverage decreased (-0.1%) to 96.294% when pulling 0a8c7d9bd6979267528d40459236e0c28484a2a6 on misc/issue-593-linting into ca8da0a046db095d7c64cc1a7031faa6e9e43855 on develop.


TRIVIAL: add missing docker/.config file

It is not possible to release the library from CIng without it.

Build failed (gate pipeline).

https://checklist.intgdc.com/job/compliance/job/gooddata-typings-merge-compliance-check/1/ : SUCCESS in 13s
https://checklist.intgdc.com/job/client-libs/job/gooddata-typings-unit-tests-zuul-docker-el7/3/ : FAILURE in 21s

added in #27


ZEVA - Avoiding user error for backdating credits issued with model year assessments

Problem Description
In order to avoid users failing to remember to check the box to back date credits (submitted with a model year report), zeva needs to better manage the credit application process during the model year reporting process for credits of the same model year as the report.
Solution Needs

It must be possible to differentiate between different model year credits so only the relevant ones are back dated
There must be no possibility of human error leading to credits being issued incorrectly in terms of their date of issuance.

Timebox

Two days

Outcome
Details describing the outcome of the research

Review the proposed solution in card #1652 (currently blocked)
Recommend a way forward, and the work required, to solve the issue

Additional Context

Going to need to dive into the database again to see how connected these pieces are.  The less connected, the more difficult it will be to automate.
100% certain that the credit transaction table is standalone, it has no foreign keys and no way to compare entries to anything if we need to.
This is also going to require lots of date checking so we need to make sure we are using the correct timestamp for each related table
This work will also require more time working with the business area for specifics.

There is a period of time between when a model year report has been submitted and when it actually gets assessed. In this period the supplier can upload additional sales submissions which could potentially alter the credits issued at the time of assessment. We need to add some additional business logic to automatically back date sales to Sept. 30th of the model year for vehicles in that model year. If vehicles are uploaded that have a model year later than the current open assessment period, then they need to be assigned a new warning “71” which is “Model year cannot be issued with an active compliance report”.
Development Requirements:

add new warning 71 to frontend app/constants/errorCodes.js to match new backend warning property 71
sales_submission_content model @property def warnings(self): will need logic to account for warning 71
Review SalesSubmission update method to ensure the RecordOfSale logic still works with warning 71
On Sales Submission create/update, write business logic similar to the following sudo code to ensure only the vehicles from the correct model year are added as pending credits:

IF OPEN MYR STATUS == [‘SUBMITTED, RECOMMENDED, or RETURNED]
IF CURRENT REAL DATE > compliace_year_sept_30 + 1 year
IF CURRENT REAL DATE > compliace_year_oct_30 + 1 year
NO ACTION ALLOWED, beyond applicable dates
ELSE IF CURRENT REAL DATE < compliace_year_oct_30 + 1 year
action allowing credits for vehicles within that model year, but set their effective date to Sept30, all other vin entries get a 71 warning flag (may need to set snapshot)
ELSE IF CURRENT REAL DATE < compliace_year_sept_30 + 1 year
ISSUE all credits as of the processing date

Alex, I have a couple of comments on what you've written on this.

For sales to be eligible to be backdated they must be both the same model year as the report and have been submitted prior to the model year report being submitted to government.
The 71 error code should apply to any sales that are not of the same model year as the report. That would include both later model years and earlier ones.

Some additional notes:
The problem:
When a model year report is submitted for model year 20xx
It includes the credits from all ZEV sales that have been submitted to government of model year 20xx but have not yet been issued (shown as pending credits)
These pending credits need to be backdated when they are issued so that the supplier has these credits in their account on the compliance date of Sept 30th (of the calendar year prior to model year 20xx)
Credits should be backdated when:
They are part of a credit application in submitted status
And a model year report has subsequently been submitted to government
And the credits are of the same model year as the submitted model year report
Otherwise, they should be tagged as 71 error and not issued.


pull request for e2e test at 11/27/2016 23:56:04

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.