Google account type impersonated_service_account not supported

Running the following command to impersonate a service account: gcloud auth application-default login --impersonate-service-account<EMAIL_ADDRESS>This generates a file like:
{
  "delegates": [],
  "service_account_impersonation_url": "xxx",
  "source_credentials": {
    "client_id": "xxx",
    "client_secret": "xxx",
    "refresh_token": "xxx",
    "type": "authorized_user"
  },
  "type": "impersonated_service_account"
}

but attempts to read this file results in the following serde error when parsing the JSON:
Error("unknown variant `impersonated_service_account`, expected `external_account` or `service_account`", line: 10, column: 40)

The code I'm using to test is below:
async fn debug_gcs() -> Result<(), anyhow::Error> {
    let credential_loader = GoogleCredentialLoader::default()
        .with_path("application_default_credentials.json");

    let credential = credential_loader.load()?.unwrap();

    // Signer will load region and credentials from environment by default.
    let token_loader = GoogleTokenLoader::new(
        "https://www.googleapis.com/auth/devstorage.read_only",
        Client::new(),
    ).with_credentials(credential);

    let signer = GoogleSigner::new("storage");

    // Construct request
    let url = Url::parse("https://storage.googleapis.com/xxx/")?;
    let mut req = reqwest::Request::new(http::Method::GET, url);

    // Signing request with Signer
    let token = token_loader.load().await?.unwrap();
    signer.sign(&mut req, &token)?;

    // Sending already signed request.
    let resp = Client::new().execute(req).await?;
    println!("resp got status: {}", resp.status());

    Ok(())
}

Thank you for bringing up this issue. Currently, we do not support impersonated_service_account. Would you be interested in helping us add this feature?
We could start from here:
https://github.com/Xuanwo/reqsign/blob/8dc135154f1d5e5db4ee3be40d0efacb45c46f7c/src/google/credential.rs#L20-L37

Hey. Yeah, if I can help, I will. I'm extremely confused by all the terminology though, and I know literally nothing about google cloud or authentication in general 😅.
I see there's already some mention of impersonated service accounts?
https://github.com/Xuanwo/reqsign/blob/main/src/google/credential/external_account.rs#L38
But that's for impersonated external service accounts? Since it's in the external account file? The google docs for all the different account types are really lacking and I have no idea about the differences between them.
But I take it you're implying that we'd have to add a brand new type like the following?
pub struct Credential {
    /// The type of the credential file.
    #[serde(rename = "type")]
    pub ty: CredentialType,

    #[serde(flatten)]
    pub(crate) service_account: Option<ServiceAccount>,
    #[serde(flatten)]
    pub(crate) external_account: Option<ExternalAccount>,
    #[serde(flatten)]
    pub(crate) impersonated_service_account: Option<ImpersonatedServiceAccount>,
}

I assume it isn't enough to simply parse the JSON (which is easy enough) though.

But I take it you're implying that we'd have to add a brand new type like the following?

Yes, we can start from here.

I assume it isn't enough to simply parse the JSON (which is easy enough) though.

Yes, we need to add new token loading logic via ImpersonatedServiceAccount too.

I'm having a spot of trouble working out what kind of request to send to google.
I have a WIP, and added JSON deserialization and a test and then the beginnings of the token loader: https://github.com/Xuanwo/reqsign/compare/main...snowdrop4:reqsign:AVK/impersonated
I literally can't find the relevant google docs page though. They don't seem to have a page that just tells you how to auth with an impersonated account.
I looked at google's python library and the requests its making when authing an impersonated account, but I can't figure out how exactly it's meant to work either.
It seems like it wants to make a request to the URL https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/xxx-01-iam@xxx-01.iam.gserviceaccount.com:generateAccessToken:generateIdToken
with the headers {'Content-Type': 'application/json', 'x-goog-api-client': 'gl-python/3.11.6 auth/2.23.4 auth-request-type/it cred-type/imp'}
and then the body {'audience': 'xxx', 'delegates': [], 'includeEmail': True}
but I can't figure out what on earth "audience" means (there's no such field in the JSON that google generates). I tried every single possible value from the JSON.

I have a WIP, and added JSON deserialization and a test and then the beginnings of the token loader: main...snowdrop4:reqsign:AVK/impersonated

Looks like we are very close!
Based the code from google golang oauth2 code, we don't need audience in the body:
https://github.com/golang/oauth2/blob/39adbb78078cc1cda488515a968b79fdb2ddb22c/google/internal/externalaccount/impersonate.go#L62-L75
	reqBody := generateAccessTokenReq{
		Lifetime:  lifetimeString,
		Scope:     its.Scopes,
		Delegates: its.Delegates,
	}
	b, err := json.Marshal(reqBody)
	if err != nil {
		return nil, fmt.Errorf("oauth2/google: unable to marshal request: %v", err)
	}
	client := oauth2.NewClient(its.Ctx, its.Ts)
	req, err := http.NewRequest("POST", its.URL, bytes.NewReader(b))
	if err != nil {
		return nil, fmt.Errorf("oauth2/google: unable to create impersonation request: %v", err)
	}

Mode code could be found at: https://github.com/golang/oauth2/blob/39adbb78078cc1cda488515a968b79fdb2ddb22c/google/google.go#L222

Thanks for your infinite patience while I bumble around.
I've never used go, but reading the source, it sent me down the track of using refresh_token.
Which lead me to all of these, which seem to more or less agree on how the request should be sent:

https://fusionauth.io/articles/oauth/complete-list-oauth-grants#flow-for-refresh-token-grant
https://frontegg.com/blog/oauth-grant-types
https://github.com/makarski/gauth-rs/blob/main/src/app/mod.rs#L170

I tried following those, and sending a POST with a body with values along the lines of:
        let req = serde_json::json!({
            "grant_type": "urn:ietf:params:oauth:token-type:refresh_token",
            "refresh_token": &cred.source_credentials.refresh_token,
            "client_id": &cred.source_credentials.client_id,
            "client_secret": &cred.source_credentials.client_secret,
            "scope": [],
        });

This seems to match what the docs/other people are doing, but I've had absolutely no luck getting any combination/permutation of this to work. Google returns the same error message every time:
{
  "error": {
    "code": 401,
    "message": "Request is missing required authentication credential. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.",
    "status": "UNAUTHENTICATED",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.ErrorInfo",
        "reason": "CREDENTIALS_MISSING",
        "domain": "googleapis.com",
        "metadata": {
          "method": "google.iam.credentials.v1.IAMCredentials.GenerateAccessToken",
          "service": "iamcredentials.googleapis.com"
        }
      }
    ]
  }
}

I'm at a loss to what I could be doing wrong, and the error message isn't super helpful.

I tried following those, and sending a POST with a body with values along the lines of:

Seems we are mixing two steps here:
First of all, we need to fetch a valid token via refresh_token.
Sending this request to https://oauth2.googleapis.com/token (I'm not sure if this endpoint is correct):
      let req = serde_json::json!({
          "grant_type": "urn:ietf:params:oauth:token-type:refresh_token",
          "refresh_token": &cred.source_credentials.refresh_token,
          "client_id": &cred.source_credentials.client_id,
          "client_secret": &cred.source_credentials.client_secret,
          "scope": [],
      });

And than, we can use the new token as auth header to send the generateAccessTokenReq to service_account_impersonation_url:
	reqBody := generateAccessTokenReq{
		Lifetime:  lifetimeString,
		Scope:     its.Scopes,
		Delegates: its.Delegates,
	}


Introduce and utilize a facility to handle server HTTP errors.

Introducing and utilizing the UrbanBusRoutingServerError class to handle server HTTP errors, particularly 500 Internal Server Error.
Bumping version number to 0.1.11.

She looks internally steady ! :+1: — Approved. :blue_heart:


Add timestamp to messages

Fixes ReadDeadline handling: previously a missed deadline invalidated all further measurements, since unconsumed packets from previous deadlines were used to infer the RTT.
Only treat errors as Fatal when necessary. Avoid Fatal errors after the initialization on the server since (a broken connection to a client should not bring down the server)
Close sessions also on the server side.
Sending and receiving messages is no longer lock-stepped.
Thanks for the suggestions in #dev

This change is

@scrye @sgmonroy
Fixes the issue where unrealistic RTTs are computed because after a missed read deadline, in the next loop iteration a packet from the previous exchange gets used to compute the time elapsed since the send.

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, 7 unresolved discussions, some commit checks failed.

go/examples/pingpong/pingpong.go, line 45 at r1 (raw file):

	ReqMsg          = "ping!" // ReqMsg and ReplyMsg length need to be the same
	ReplyMsg        = "pong!"
	TSLen           = 10 // length of unix timestamp == len(strconv.FormatInt(time.Now().Unix(), 10))

It would be simpler to just encode the timestamp as binary. Marshal:
common.Order.PutUint64(b, time.Now().UnixNano())
...
time.Unix(0, common.Order.Uint64(b))

go/examples/pingpong/pingpong.go, line 131 at r1 (raw file):

	defer qstream.Close()
	log.Debug("Quic stream opened", "local", &local, "remote", &remote)
	wg := new(sync.WaitGroup)

I don't think you need a waitgroup for this:
go Send(..)
Read()

should do the right thing. If the read loop is finished, then there's no point in waiting for the sending loop.

go/examples/pingpong/pingpong.go, line 189 at r1 (raw file):

			if nerr, ok := err.(net.Error); ok && nerr.Timeout() {
				log.Debug("ReadDeadline missed", "err", err)
				// ReadDeadline is only set after we are done writting

writing

go/examples/pingpong/pingpong.go, line 215 at r1 (raw file):

		before := time.Unix(unixTs, 0)
		elapsed := after.Sub(before)
		fmt.Printf("[%v] Received %d bytes from %v: seq=%d RTT=%s\n", before.Unix(), read, &remote, i, elapsed)

I don't think it's useful to print the unix timestamp. The RTT is the relevant part.
I would also round the elapsed time: elapsed.Round(time.Microsecond), so that it's less noisy, while still sufficiently precise.

go/examples/pingpong/pingpong.go, line 234 at r1 (raw file):

		if err != nil {
			log.Error("Unable to accept quic session", "err", err)
			qsess.Close(nil)

Are you sure that qsess is non-nil if Accept() returns an error? That would not be what i'd expect.

go/examples/pingpong/pingpong.go, line 254 at r1 (raw file):

}

func handleClient(qsess quic.Session) {

This breaks our lint process if you happen to have quic-go in your GOPATH. That's why all the other quic references are commented out.

go/examples/pingpong/pingpong.go, line 285 at r1 (raw file):
That doesn't sound right. https://golang.org/pkg/builtin/#copy:

Copy returns the number of elements copied, which will be the minimum of len(src) and len(dst).

Comments from Reviewable

Review status: all files reviewed at latest revision, 7 unresolved discussions, some commit checks failed.

go/examples/pingpong/pingpong.go, line 215 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
I don't think it's useful to print the unix timestamp. The RTT is the relevant part.
I would also round the elapsed time: elapsed.Round(time.Microsecond), so that it's less noisy, while still sufficiently precise.

I added timestamp to the output because the remote end goes down sometimes during longer runs. So having a timestamp helps correlating events.
I also have a version with an additional format flag, where the user can pass the format string (would also give control over truncating the RTT) as a flag at runtime (with a default one similar to the current one).
Would that be a better solution? Or just log the more detailed output and only print the uncluttered view?

go/examples/pingpong/pingpong.go, line 234 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
Are you sure that qsess is non-nil if Accept() returns an error? That would not be what i'd expect.

No you are right, underneath it calls net.Listener.Accept() which returns a nil qsess when err is non-nil

go/examples/pingpong/pingpong.go, line 285 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
That doesn't sound right. https://golang.org/pkg/builtin/#copy:

Copy returns the number of elements copied, which will be the minimum of len(src) and len(dst).

This I agree with. And here len(src)==len(dst) by definition (replyMsgLen:=len(ReplyMsg)), the thing is that len(ReqMsg) might be smaller than len(ReplyMsg).
So is your suggestion to use copy(b[:len(ReqMsg)], ReplyMsg) and possibly have ReplyMsg truncated?

Comments from Reviewable

Review status: 0 of 1 files reviewed at latest revision, 7 unresolved discussions, some commit checks failed.

go/examples/pingpong/pingpong.go, line 131 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
I don't think you need a waitgroup for this:
go Send(..)
Read()

should do the right thing. If the read loop is finished, then there's no point in waiting for the sending loop.

Done.

go/examples/pingpong/pingpong.go, line 189 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
writing

Done.

go/examples/pingpong/pingpong.go, line 234 at r1 (raw file):
Previously, FR4NK-W wrote…
No you are right, underneath it calls net.Listener.Accept() which returns a nil qsess when err is non-nil

Done.

Comments from Reviewable

Review status: 0 of 1 files reviewed at latest revision, 6 unresolved discussions, some commit checks failed.

go/examples/pingpong/pingpong.go, line 45 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
It would be simpler to just encode the timestamp as binary. Marshal:
common.Order.PutUint64(b, time.Now().UnixNano())
...
time.Unix(0, common.Order.Uint64(b))

Ping.

go/examples/pingpong/pingpong.go, line 215 at r1 (raw file):
Previously, FR4NK-W wrote…
I added timestamp to the output because the remote end goes down sometimes during longer runs. So having a timestamp helps correlating events.
I also have a version with an additional format flag, where the user can pass the format string (would also give control over truncating the RTT) as a flag at runtime (with a default one similar to the current one).
Would that be a better solution? Or just log the more detailed output and only print the uncluttered view?

I'd suggest in this case a -v (verbose) flag that, if included, prints the full timestamp at the end of the line.

go/examples/pingpong/pingpong.go, line 254 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
This breaks our lint process if you happen to have quic-go in your GOPATH. That's why all the other quic references are commented out.

Ping.

go/examples/pingpong/pingpong.go, line 285 at r1 (raw file):
Previously, FR4NK-W wrote…
This I agree with. And here len(src)==len(dst) by definition (replyMsgLen:=len(ReplyMsg)), the thing is that len(ReqMsg) might be smaller than len(ReplyMsg).
So is your suggestion to use copy(b[:len(ReqMsg)], ReplyMsg) and possibly have ReplyMsg truncated?

The simplest thing is to extract the timestamp, and then write a new payload including the sender's timestamp. That way the relative lengths of ReqMsg and ReplyMsg aren't relevant.

go/examples/pingpong/pingpong.go, line 134 at r2 (raw file):

}

func Send(qstream quic.Stream) {

Breaks lint.

go/examples/pingpong/pingpong.go, line 169 at r2 (raw file):

}

func Read(qstream quic.Stream) {

Breaks lint.

Comments from Reviewable

Reviewed 1 of 1 files at r3.
Review status: all files reviewed at latest revision, 6 unresolved discussions, some commit checks failed.

go/examples/pingpong/pingpong.go, line 45 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
Ping.

Done.

go/examples/pingpong/pingpong.go, line 215 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
I'd suggest in this case a -v (verbose) flag that, if included, prints the full timestamp at the end of the line.

Added the flag, having the RTT at the end of the line gives a quick grasp of the RTT variance

go/examples/pingpong/pingpong.go, line 254 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
Ping.

Done.

go/examples/pingpong/pingpong.go, line 285 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
The simplest thing is to extract the timestamp, and then write a new payload including the sender's timestamp. That way the relative lengths of ReqMsg and ReplyMsg aren't relevant.

Done.

go/examples/pingpong/pingpong.go, line 134 at r2 (raw file):
Previously, kormat (Stephen Shirley) wrote…
Breaks lint.

Done.

go/examples/pingpong/pingpong.go, line 169 at r2 (raw file):
Previously, kormat (Stephen Shirley) wrote…
Breaks lint.

Done.

Comments from Reviewable

Reviewed 1 of 1 files at r3.
Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

go/examples/pingpong/pingpong.go, line 215 at r1 (raw file):
Previously, FR4NK-W wrote…
Added the flag, having the RTT at the end of the line gives a quick grasp of the RTT variance

Alrighty. One minor thing - use %s for the timestamp, as it implements Stringer.

go/examples/pingpong/pingpong.go, line 275 at r3 (raw file):

		// extract timestamp
		ts := make([]byte, 8)
		copy(ts, b[reqMsgLen:reqMsgLen+TSLen])

This is slightly more work than just:
ts := common.Order.Uint64(b[reqMsgLen:])
...
common.Order.PutUint64(b[replyMsgLen:])

Comments from Reviewable

Reviewed 1 of 1 files at r4.
Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

go/examples/pingpong/pingpong.go, line 215 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
Alrighty. One minor thing - use %s for the timestamp, as it implements Stringer.

Done.

go/examples/pingpong/pingpong.go, line 275 at r3 (raw file):
Previously, kormat (Stephen Shirley) wrote…
This is slightly more work than just:
ts := common.Order.Uint64(b[reqMsgLen:])
...
common.Order.PutUint64(b[replyMsgLen:])

Done.

Comments from Reviewable

Reviewed 1 of 1 files at r4.
Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

go/examples/pingpong/pingpong.go, line 205 at r4 (raw file):

		elapsed := after.Sub(before)
		if *verbose {
			fmt.Printf("[%s]\tReceived %d bytes from %v: seq=%d RTT=%s\n", before.Unix(), read, &remote, i, elapsed)

Line length (code should be wrapped before reaching 100 lines, assuming tabs are 4 spaces).

go/examples/pingpong/pingpong.go, line 285 at r4 (raw file):

			continue
		} else if written != len(ReplyMsg)+TSLen {
			log.Error("Wrote incomplete message", "expected", len(ReplyMsg)+TSLen, "actual", written)

Line length.

Comments from Reviewable

Review status: 0 of 1 files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

go/examples/pingpong/pingpong.go, line 205 at r4 (raw file):
Previously, kormat (Stephen Shirley) wrote…
Line length (code should be wrapped before reaching 100 lines, assuming tabs are 4 spaces).

Done.

go/examples/pingpong/pingpong.go, line 285 at r4 (raw file):
Previously, kormat (Stephen Shirley) wrote…
Line length.

Done.

Comments from Reviewable

Reviewed 1 of 1 files at r6.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


feat: Create a Python Typing Game

Issue Title: Create a Python Typing Game
Issue Description:
I propose the addition of a new project, a Python Typing Game, to the Python_Projects repository. Typing games are both fun and educational, helping users improve their typing speed and accuracy.
Project Details:

Name: Python Typing Game
Technologies: Python

Additional Information (if available):
If there are specific guidelines or requirements for contributing to the repository, please provide the necessary details to ensure a smooth integration of this project.
I'm eager to work on this project and look forward to the opportunity to contribute to the repository. Thank you for considering this addition.

@purnasth, I am glad to know that you wanted to make your contribution towards this repository. Follow the directed steps to contribute towards this repository :

Fork this repo.
Add your files to appropriate directories.
Commit changes.
Create a pull request.

Hope to see your invaluable contribution soon...


Remove deletion of Job Queue Entries inside Codeunit 448 JobQueueDispatcher Function WaitForOthersWithSameCategory Line #106

Hi,
17.6 introduced new functionality that deletes Job Queue Entries that are in process in the same JQ Category if the system can't find a related Task Process - this is causing JQEs to be deleted incorrectly. Please revert back to version 17.4 for function WaitForOthersWithSameCategory.

Thank you for reaching out. Your request could be reporting a product bug not related to the AL application extensibility. Please reach out to the relevant support channels:

For collaboration in preview or beta versions of AL Language in Visual Studio Code (aka ModernDev), use GitHub (https://github.com/microsoft/al).
For Microsoft partners, for versions already in general availability and supported, file requests through Microsoft Partnersource (https://mbs.microsoft.com/partnersource/).
For ISVs/VARs who have discovered a bug in a in preview or beta version, use MS Collaborate (https://docs.microsoft.com/en-us/collaborate/).
For Business Central customers who have issues or found bugs, please contact your Microsoft partner.
For the new features please submit a product suggestion on https://aka.ms/bcideas


Merge "develop" branch into "master"

tl;dr: The develop branch is going away in favor of master for active development and pull requests.
Hey all,
I wanted to give a quick heads-up that we'll be changing our branching model slightly over the next few days to 1. better align with other projects on GitHub, and 2. set clearer expectations on how and where to open pull requests. It should also make it simpler to identify and isolate releases, as well.
What's changing?
Long story short, the develop branch will be merged into master.
Here's a more detailed list of changes:

develop branch goes away. Pull requests should not be opened against this branch moving forward.
master takes over from develop, becoming the "active development" branch. Pull requests should only be opened against this branch moving forward.
For convenience, the dist folder for compiled CSS and JS will no longer be tracked on master, similar to develop today. To view the contents of dist, either view the contents of a release commit or clone and build Fabric locally.
Each release will have its own tagged branch, e.g. release/1.1.0. Compiled CSS and JS files will still be checked into the dist folder on each release branch.

Why the need for this change?
Internally, we had been following a branching model similar to this one, where master  is used for  stable, tagged releases with precompiled contents, while develop is used for daily development--naturally :)
This model has mostly worked pretty great for our team. However, on GitHub, using different "default" and "pull request" branches is pretty confusing, and is different from how other projects run. As a result, it's been unclear to contributors whether to open pull requests against develop or master, resulting in a mix of both. So, in the spirit of simplicity and predictability, we're trimming down to master only.
How will this affect me?
For the most part, this change should be pretty clean and painless. If you have a branch stemming off of develop, you will want to merge master into your branch instead of develop to ensure conflicts are resolved.
Thanks!
- The Office UI Fabric team

This merge is complete as of https://github.com/OfficeDev/Office-UI-Fabric/issues/146. develop will be deleted shortly.
As a reminder, all pull requests should now be opened against master. Thanks!


Why no TYPO3 9 Support

WHY???????? PLEASE !!!!!

Doesen't work version 2.0 https://github.com/Hauer-Heinrich/hh_accordion/tree/0.2.0 not for you?

Oops, an error occurred!
Undeclared arguments passed to ViewHelper TYPO3\CMS\Fluid\ViewHelpers\ImageViewHelper: loading. Valid arguments are: additionalAttributes, data, class, dir, id, lang, style, title, accesskey, tabindex, onclick, alt, ismap, longdesc, usemap, src, treatIdAsReference, image, crop, cropVariant, width, height, minWidth, minHeight, maxWidth, maxHeight, absolute

oh you are right the "loading" attribute exists only since TYPO3 10 - should be fixed with 0.2.1

Thank You still waiting for 0.2.1

Please report when you are finish with 2.0.1

@typo3max have you additional error with this version 0.2.1?
Info: unfortunately the TER does not update this version - so you have to download it manually

when i would find the link to download?!

https://packagist.org/packages/hauerheinrich/hh-accordion#0.2.1
https://github.com/Hauer-Heinrich/hh_accordion/tree/TYPO3-9
https://github.com/Hauer-Heinrich/hh_accordion/tree/0.2.1

I hope you get the extension published soon!

 Bist du am Schlafen?

oh you are right the "loading" attribute exists only since TYPO3 10 - should be fixed with 0.2.1 : https://github.com/Hauer-Heinrich/hh_accordion/tree/TYPO3-9

@typo3max have you additional error with this version 0.2.1? Info: unfortunately the TER does not update this version - so you have to download it manually

Can you make a package to download, thank you!

Oops, an error occurred!
Undeclared arguments passed to ViewHelper TYPO3\CMS\Fluid\ViewHelpers\ImageViewHelper: loading. Valid arguments are: additionalAttributes, data, class, dir, id, lang, style, title, accesskey, tabindex, onclick, alt, ismap, longdesc, usemap, src, treatIdAsReference, image, crop, cropVariant, width, height, minWidth, minHeight, maxWidth, maxHeight, absolute

any answer? the version 0.2.1 dont work, same error!

ah yes sorry - new version:
https://github.com/Hauer-Heinrich/hh_accordion/tree/0.2.2


if the background is solid and fully opaque then...

you don't need to have a situation of transparency with a solid fill below.
It can be easier, where the div below does nothing, and just the webgl context initialises the background with a solid opaque fill.
I have no idea if this is worth doing, because it might be added complication that streamlines something where there is no performance gain.
But maybe it's worth adding a comment somewhere explaining this edge case, just to say that someone thought about it.

so this feels like an unnecessary optimisation to me. I think that we should stick to transparent 3js backgrounds and then render actual backgrounds on the div/canvas beneath. can't see that this would necessarily make anything quicker tbh

After having had a look at the background code, I think that we should avoid using webgl for background fills of any kind. it makes more sense to me that we have it just handling 3d rendering, and the background colours/gradients are handled externally


Resizing Regions sometimes moves inner lyphs outside of region

Inner lyphs should always stay inside their hosted regions when resizing the region.
Video showing the error:
https://user-images.githubusercontent.com/4562825/145727080-3897e0e1-87d9-4824-88c7-a3f722474e3c.mp4

Fixed on latest demo branch


Fixed curl's http method written in README.md

Methods that mutate state (restart, add, delete broker, etc) with the new version(<IP_ADDRESS>) are no longer accepting GET requests, but changed to accept only POST.
So, I fixed the curl's HTTP method written in the README.md.
Please confirm this PR.
Thank you

Thanks for the contribution!

Thanks for the review @steveniemitz !


fix: Improve waiting for cluster operators check

Replace seven static tasks to check cluster operators, with a task loop.
Signed-off-by: Klaus Smolin<EMAIL_ADDRESS>

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Check if 'Change wi-fi settings' message is already displayed to user

The message "Your current download settings only allow downloads over Wi-Fi." was getting displayed twice as per screen shot below.
This has been handled to show the message only once as per Lou's comment on the jira ticket.
Please review - @rohan-dhamal-clarice @hanningni @aleffert
JIRA: https://openedx.atlassian.net/browse/MOB-1578

Thanks for the pull request, @shahidtamboli! It looks like you're a member of a company that does contract work for edX. If you're doing this work as part of a paid contract with edX, you should talk to edX about who will review this pull request. If this work is not part of a paid contract with edX, then you should ensure that there is an OSPR issue to track this work in JIRA, so that we don't lose track of your pull request.
To automatically create an OSPR issue for this pull request, just visit this link: http://openedx-webhooks.herokuapp.com/github/process_pr?repo=edx%2Fedx-app-android&number=175

@hanningni - I have updated the code to use message event. Please review.
cc - @rohan-dhamal-clarice


Added clarification to use bash

Some linux distros have sh symlinked to dash. So I have added a clarification to use bash for the distros.

Thanks!

Another way to fix this could be to change the shebang to bash (or Zsh) in the install script.

Done: 533325c39d412b9b72fe5a23330d84d68a2ce266


Library import<PHONE_NUMBER>

PR was created by rightlib sync workflow run

Correct import is here: https://github.com/ydb-platform/ydb/pull/12958

Correct import is here: https://github.com/ydb-platform/ydb/pull/12958


Automated cherry pick of #8168: fix: emulated wire not sync vpc shared info

Cherry pick of #8168 on release/3.3.
#8168: fix: emulated wire not sync vpc shared info

/lgtm
/approve


Fix unreferenced variable in get_user_info

The previous fix (#862) left the code broken, since in case of exception, user_info was not declared.

This change is

Thanks!


Add error codes to the spec to allow brokers to communicate about specific nature of failures

During the November 28 F2F we collectively agreed that the spec should include error codes that a broker could return as part of an error response to provide information about the specific cause of a failure.
Some examples:

Couldn't create a binding because an earlier update of an instance failed
Update instance failed because the requested plan change was unsupported

Related to this: perhaps certain error codes could be designated as retryable so that the platform could automatically retry.

This is now resolved and we have a standard set of error codes in the spec.


Update type promotion rules for complex dtypes

Add a table with promotion rules
Update type promotion lattice diagram

Closes gh-477
Closes gh-478
On gh-478, @leofang made a different suggestion regarding the actual rules (mixed-kind real/complex allowed), so let's discuss that there before merging this. Marking as draft for now.

Based on discussions on gh-478 and during the 22 September 2022 consortium meeting, we should update this PR to have a single floating-point table with both real and complex floating-point data types, as proposed by Leo (see https://github.com/data-apis/array-api/issues/478#issuecomment-1270294398).
TensorFlow's lack of real-complex dtype promotion was not considered a blocker. An increase in the number of kernels (i.e., implementations for specific dtype pairs) was also not considered a blocker. The number of kernels an array library chooses to implement is an implementation detail; from a user POV, the expectation is that mixed real-complex promotion should just work.

Okay, this should be good to go now (please squash commits when merging). Apologies for the delay.


Travis and Jenkins

If you're interested, I've setup a .travis.yml for build testing on Linux and OS X and a Jenkins job for building on FreeBSD. After merging you'll just need to login to Travis and enable to build for this repo.

Cool, thanks! I have enabled Travis CI for this repository. Please collapse your commits into one with git rebase, then I'll merge.

Commits collapsed


Vim9: type checking uses inferred "any" type inconsistently for list/dict of funcrefs

Describe the bug
In Vim9 script, type checking uses an inferred any type inconsistently for a list/dict of funcrefs.
To Reproduce
Run this shell command:
vim -Nu NONE -S <(cat <<'EOF'
    vim9script
    def ExpectNumber(x: number)
    enddef
    def ExpectString(x: string)
    enddef
    var l: list<func(bool)> = [ExpectNumber, ExpectString]
EOF
)

No error is given for the assignment; even though none of the function signatures match the func(bool) type specified in the declaration of the l variable.
Now, run this other shell command:
vim -Nu NONE -S <(cat <<'EOF'
    vim9script
    def ReturnNumber(): number
        return 123
    enddef
    def ReturnString(): string
        return 'string'
    enddef
    var l: list<func(): bool> = [ReturnNumber, ReturnString]
EOF
)

This time, a type mismatch error is given:
E1012: Type mismatch; expected list<func(): bool> but got list<func(): any>

Expected behavior
Not sure, but to be consistent, it seems that either the first command should give an error, like the second one; or the second command should not give any error, like the first one.
IMO, the most useful choice would be for the second command to give an error like the first one.
Environment

Vim version: 8.2 Included patches: 1-3081
OS: Ubuntu 20.04.2 LTS
Terminal: XTerm(353)

Additional context
I think the reason why Vim doesn't give an error in the first command is because of the any type which was inferred for the functions argument:
vim9script
def ExpectNumber(x: number)
enddef
def ExpectString(x: string)
enddef
echo [ExpectNumber, ExpectString]->typename()

list<func(any)>
          ^^^

During type checking, it seems that this inferred any matches any type; including the bool that we wrote in the list variable declaration:
var l: list<func(bool)> = [ExpectNumber, ExpectString]
                 ^--^

But that's not how type checking uses an any inferred for a funcref return type.  If it was, there would be no error in the second command:
E1012: Type mismatch; expected list<func(): bool> but got list<func(): any>
                                                                       ^^^

Notice the any at the end of the message.  It means that Vim is much stricter when checking the return type; it doesn't accept any return type; it really wants all funcrefs to have the return type any.
IOW, the only way to fix this error is to write any for the return type:
                     ✘
                    v--v
var l: list<func(): bool> = [ReturnNumber, ReturnString]

→

var l: list<func(): any> = [ReturnNumber, ReturnString]
                    ^^^
                     ✔

The fact that an inferred any is used differently for a function argument compared to a function return value seems inconsistent.  Is this working as intended?  If so, maybe it should be documented.

IMO, the behavior in the second command is good, because it gives us the most guarantees about the validity of our code.  For example, if we write this:
var l: list<func(): number> = [A, B, C]

And Vim doesn't complain, then we have the guarantee that all 3 functions A, B, C do return numbers.
The only exception to this guarantee is the any return type:
var l: list<func(): any> = [A, B, C]

This time, if Vim doesn't complain, it doesn't mean that each of the 3 functions can return any type of values.  It means that – as a whole – the set of the 3 return types could contain any type.  IOW, it doesn't mean anything useful.  It's a bit like saying "I have no idea what any of these functions return".
OTOH, maybe the behavior in the first command should be changed because:

it would be more consistent with the second one
it would give us more guarantees about the validity of the argument types that we write

So maybe this command:
vim9script
def ExpectNumber(x: number)
enddef
def ExpectString(x: string)
enddef
var l: list<func(bool)> = [ExpectNumber, ExpectString]

Should give an error, such as:
E1012: Type mismatch; expected list<func(bool)> but got list<func(any)>

And to fix this, we should have to rewrite our declaration like this:
                  ✘
                 v--v
var l: list<func(bool)> = [ExpectNumber, ExpectString]

→

var l: list<func(any)> = [ExpectNumber, ExpectString]
                 ^^^
                  ✔

it really wants all funcrefs to have the return type any.

No, sorry, that's not what I meant.  Vim just wants any in the declaration.  But that doesn't change the rest of the post.

The reason that "any" is accepted for the argument type is that lambda's may use "any" and in that case we can't give an error.
The argument type will be checked at runtime.
We could perhaps add a flag in the type that the function type comes from a lambda, but that gets complicated.
It would be nice to get an error more early, but other than that it's not really wrong.


invalid value encountered in cast

When opening a dataset with triangles and squares, there are _FilllValue values in the face_node_connectivity. This is expected. However, it seems that a warning was introduced "RuntimeWarning: invalid value encountered in cast". This also occurs when testing with older xugrid versions, so it might be because of xarray or a related package that I only see this now.
Figures all seem fine, so this issue is just to check if the warning should be supressed or removed. I noticed the face_node_connectivity (the int32 variable mesh2d_face_nodes in this example) is converted to nans by xarray, since it contains nans. The function _prepare_connectivity in xugrid\ugrid\ugridbase.py then tries to cast this value back to int again.
The function searches for the _FillValue attribute in da.attrs, but with xarray this attribute is located in da.encoding instead. Still is_fill results in a correct boolean. However, the fillvalues are not replaced by fill_value before the array is being converted back to int32 again. I would suggest adding data[is_fill] = fill_value right before cast = data.astype(dtype, copy=True):
https://github.com/Deltares/xugrid/blob/ae046ce71cf2bfdc38536adbaa66242e97a1f852/xugrid/ugrid/ugridbase.py#L363-L382
(and probably removing cast[is_fill] = fill_value)
Either way, the resulting face_node_connectivity seems to be correct (0-based and -1 as fillvalue)
A MWE below:
import warnings
import xugrid as xu
import xarray as xr
from netCDF4 import Dataset

warnings.filterwarnings("error") #set warnings as errors
file_nc = r'c:\DATA\dfm_tools_testdata\DFM_grevelingen_3D\Grevelingen-FM_0003_map.nc'

#original data is int32
print('netcdf4 Dataset')
data_nc = Dataset(file_nc)
print(data_nc.variables['mesh2d_face_nodes'].dtype)
#int32
print(data_nc.variables['mesh2d_face_nodes']._FillValue)
#-999
print(data_nc.variables['mesh2d_face_nodes'][0,:].data)
#[   1    5    7 -999]

#xarray data is converted to floats since it contains nan-values
print('xarray Dataset')
ds = xr.open_dataset(file_nc)
print(ds['mesh2d_face_nodes'].dtype)
#float64
print(ds['mesh2d_face_nodes'].encoding['_FillValue'])
#-999
print(ds['mesh2d_face_nodes'].isel(nmesh2d_face=0).to_numpy())
#[ 1.  5.  7. nan]

#when opening with xugrid, this results in a warning (can be raised as error to get the traceback), but the face_node_connectivity seems to be ok.
print('xugrid Dataset')
uds = xu.open_dataset(file_nc)
#RuntimeWarning: invalid value encountered in cast
print(uds.grid.face_node_connectivity[0,:])
#[ 0  4  6 -1]

Great, this is very helpful!
As far as I can tell, the _FillValue should be present in the attributes according to the UGRID conventions: https://ugrid-conventions.github.io/ugrid-conventions/
But I should take another look at the .encoding property.
Moving the replacement up is indeed the better choice and will silence the warning (at the minor cost of creating another copy of the data in memory).

You are right, but xarray moves some of these attributes to the encoding when os uses them for processing. _FillValue is one of these moved attrs (used to replace fillvalues with nan in the arrays), but it also goes for the 'units' attr of the time variable (used to decode the time variable into datetimes).


Proposal: Allow 'missing' types to be treated as optional parameters in function assignment

I suggest to allow treating undefined, possibly void and never as well, types to be treated as optional arguments in function assignment.
It doesn't break type system since not passing argument is same as passing undefined explicitly.
let f= (x: undefined) =>{ }
let g = () => { }

f = g; // Compiles today
g = f;

Duplicate of https://github.com/Microsoft/TypeScript/issues/12400


Add HTTP/0.9 responses support

This PR just adds an option to ClientBuilder which enables http09_responses on the hyper client. As it uses hyper it doesn't have wasm support.
Tell me if anything needs to be changed or if I need to add wasm support.

Looks like this needs to bump the minimum version of hyper in the Cargo.toml to at least 0.14.5.

Finished in #1427, thank you!


disable RefineryCMS member action for coords

Brenda ran into an issue when she was inadvertently given the role of "syndicate_coordinator" where the RefineryCMS action was taking her to edit county pages.  Unless county pages are planned for CEN, we need to disable  this action in the userid_role.rb for freecen syndicate and county coords to prevent confusion.

Yes, county pages are wanted (currently "status page"). County Coord needs, Syndicate Coord doesn't need.  At the moment they do this on independent websites.

Unable to reproduce the problem without directly typing in the URL for the /cms/refinery/county_pages . The RefineryCMS member action is not presented to syndicate coords, so perhaps when the action did not appear, maybe typing refinery into the browser URL navigation field resulted in it auto-completing to that previously-visited URL?  Hard to know without more info. I do not think there is anything left to be done here unless someone has a similar issue in the future. Recommend we close this.

Yes, to close.


Fastpow

While profiling the viscosity computations I saw that ~75% of the time of the whole local iterations routine was spend in doing the powers with floating point exponents of the rheology laws.  I added the faster  power:
# fast exponential
function fastpow(x::Number, n::Integer)
    n > 3 && return exp(log(x)*n)
    return x^n
end

fastpow(x::Number, n::AbstractFloat) =  exp(log(x)*n)

I obsserved a  ~75% speed up in the local iterations  calculation using this approach. By computing the powers like this there's a slight trade-off in accuracy, but I would say its acceptable:
julia> @btime normal_power()
  318.598 ns (0 allocations: 0 bytes)
# 4 iteratios and residual = 5.892568764240876e-10

julia> @btime fast_power()
  182.568 ns (0 allocations: 0 bytes)
# 4 iteratios and  residual 5.89256100096274e-10

Did you observe this behaviour consistently for CPU and GPU arrays?

Did you observe this behaviour consistently for CPU and GPU arrays?

Yes, these are the results of the benchmarks:
fastpow(x::Number, n::Integer) =  exp(log(x)*n)
fastpow(x::Number, n::AbstractFloat) =  exp(log(x)*n)

@parallel_indices (i,j,k) function normal_power(C, A, B, n)
    C[i,j,k] = A[i,j,k]^(1-1/n) + B[i,j,k]^n
    return
end

@parallel_indices (i,j,k) function fast_power(C, A, B, n)
    C[i,j,k] = fastpow(A[i,j,k], 1-1/n) + fastpow(B[i,j,k], n)
    return
end

n = 128
A, B, C = ntuple(_->CUDA.rand(Float64, n,n,n), Val(3))
# A, B, C = ntuple(_->CUDA.rand(Float32, n,n,n), Val(3))
# A, B, C = ntuple(_->rand(Float64, n,n,n), Val(3))
# A, B, C = ntuple(_->rand(Float32, n,n,n), Val(3))

## FLOATING POINT EXPONENTS
@btime @parallel normal_power(C, A, B, 3.3)
# CUDA - Float64 : 5.031 ms (168 allocations: 8.89 KiB)
# CUDA - Float32 : 4.976 ms (168 allocations: 8.89 KiB)
# CPU  - Float64 : 28.745 ms (168 allocations: 8.89 KiB)
# CPU  - Float32 : 29.465 ms (168 allocations: 8.89 KiB)

@btime @parallel fast_power(C, A, B, 3.3)
# CUDA - Float64 : 2.825 ms (168 allocations: 8.89 KiB)
# CUDA - Float32 : 1.330 ms (168 allocations: 8.89 KiB)
# CPU  - Float64 : 17.975 ms (168 allocations: 8.89 KiB)
# CPU  - Float32 : 17.935 ms (168 allocations: 8.89 KiB)

## INTEGER POINT EXPONENTS
@btime @parallel normal_power(C, A, B, 4)
# CUDA - Float64 : 4.965 ms (168 allocations: 8.89 KiB)
# CUDA - Float32 : 2.785 ms (168 allocations: 8.89 KiB)
# CPU  - Float64 : 16.772 ms (168 allocations: 8.89 KiB)
# CPU  - Float32 : 16.138 ms (168 allocations: 8.89 KiB)

@btime @parallel fast_power(C, A, B, 4)
# CUDA - Float64 : 2.874 ms (168 allocations: 8.89 KiB)
# CUDA - Float32 : 946.482 ms (168 allocations: 8.89 KiB)
# CPU  - Float64 : 18.042 ms (168 allocations: 8.89 KiB)
# CPU  - Float32 : 15.340 ms (168 allocations: 8.89 KiB)

The speed-up is even larger for single precision.

Surprising but convincing results


OL tag updated to 2022.05.18_02.12.32 from 2022.05.17_01.52.42`

Signed-off-by: vijayank88<EMAIL_ADDRESS>OpenLane tag updated to 2022.05.18_02.12.32 from 2022.05.17_01.52.42 as its enabled PL_ROUTABILITY_DRIVEN and PL_TIME_DRIVEN
Following MPW-5 design issues got fixed:
FMAC FMAC_wrapper: wrong FP_PDN_HOOKS updated based on macro.cfg to fix LVS issue.
hack_soc_wrapper: wrong FP_PDN_HOOKS updated based on macro.cfg to fix LVS issue.
mpw5_microwatt Microwatt_FP_DFFRFile & Microwatt_multiply_add: Disabled ECO_ENABLE to pass the flow.

@dralabeing  FYI

@vijayank88 we now have a green CI, please merge the changes in the main branch into yours. Green checks will be required to merge a PR into the main branch.

@vvbandeira
CI fails during OpenLane build itself.
Check the logs: https://github.com/The-OpenROAD-Project/OpenLane-MPW-CI/pull/40/checks?check_run_id=6534960040
Downloading pre-built tarball for 41c0908b47130d5675ff8484255b43f66463a7d6…  9…
Traceback (most recent call last):
  File<EMAIL_ADDRESS>line 441, in _error_catcher
    yield
  File<EMAIL_ADDRESS>line 522, in read
    data = self._fp.read(amt) if not fp_closed else b""
  File "/usr/lib64/python3.6/http/client.py", line 459, in read
    n = self.readinto(b)
  File "/usr/lib64/python3.6/http/client.py", line 503, in readinto
    n = self.fp.readinto(b)
  File "/usr/lib64/python3.6/socket.py", line 586, in readinto
    return self._sock.recv_into(b)
  File "/usr/lib64/python3.6/ssl.py", line 971, in recv_into
    return self.read(nbytes, buffer)
  File "/usr/lib64/python3.6/ssl.py", line 833, in read
    return self._sslobj.read(len, buffer)
  File "/usr/lib64/python3.6/ssl.py", line 590, in read
    v = self._sslobj.read(len, buffer)
ConnectionResetError: [Errno 104] Connection reset by peer

@vvbandeira
In production-samll-1 CI peripheral-extender shows LVS failed. But in my local test its passed without any issues.
Is possible to run CI again for that alone?


Added FallbackBehavior support

Connected with #354
Now, it's possibly to specify fallback behavior:
<TextBlock Text="{lex:Loc UndefinedKey, FallbackBehavior=Default}" />
<TextBlock Text="{lex:Loc UndefinedKey, FallbackBehavior=Key}" />
<TextBlock Text="{lex:Loc UndefinedKey, FallbackBehavior=EmptyString}" />

It will be used only if key wasn't found anywhere, including MissingKeyResult event.
@konne, @superware, please check

Hi @Karnah, thank you for everything, can you please release a new version to NuGet?

@konne, could you merge and publish new release?


pytest 5.1.0 seems to break the test adapter

Issue Type: Bug
After updating VSCode from v1.36.1 to v1.37.1 (in WSL), pytest unit tests are no longer displaying green/red status in the side bar.  An error pop-up is displayed with the following message:
There was an error in running the tests.
Source Python (Extension)
The OUTPUT tab indicates that the test passed, but there is also an error message that seems like it is related to the extension issue:
============================= test session starts ==============================
platform linux -- Python 3.6.8, pytest-5.1.0, py-1.8.0, pluggy-0.12.0
rootdir: /mnt/c/Users/.../
plugins: cov-2.7.1
collected 1 item

tests/test___init__.py .                                                 [100%]

-------------- generated xml file: /tmp/tmp-2499XLU6ay233ncl.xml ---------------
============================== 1 passed in 0.06s ===============================
Error: TypeError: Cannot read property '$' of undefined

Extension version: 2019.8.30787
VS Code version: Code 1.37.1 (f06011ac164ae4dc8e753a3fe7f9549844d15e35, 2019-08-15T16:17:55.855Z)
OS version: Windows_NT x64 10.0.17134
Remote OS version: Linux x64 4.4.0-17134-Microsoft

System Info

Item
Value

CPUs
Intel(R) Xeon(R) CPU           X5650  @ 2.67GHz (12 x 3800)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwareoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_deferred_display_list: disabled_offskia_renderer: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
24.00GB (14.93GB free)

Process Argv
--folder-uri=vscode-remote://wsl+default/mnt/c/Users/.../ --remote=wsl+default

Screen Reader
no

VM
50%

Item
Value

Remote
WSL

OS
Linux x64 4.4.0-17134-Microsoft

CPUs
Intel(R) Xeon(R) CPU           X5650  @ 2.67GHz (12 x 3800)

Memory (System)
24.00GB (14.93GB free)

VM
50%

@krazyace78 @pvscbot
Also mentioning @Johnnyxy and @BLeAm as I see they posted a reaction to it.
I have the same issue.
I believe this is unrelated to updating Visual Studio Code. I just ran some tests, and the issue seems to be with pytest 5.1.0.
Try downgrading to pytest 5.0.1 (via pip install -U pytest==5.0.1), as that fixed it for me.

@Marsfan Thank you for mentioning me and the workaround.

Thank you for the workaround @Marsfan!

I have the same issue, and the workaround did the trick for me. Thanks @Marsfan!

+1 works for me now @Marsfan
In case someone has the same issues: to downgrade pytest to 5.0.1, uninstall it first (pipenv uninstall pytest), then add the dependency in your Pipfile as "<=5.0.1" and re-install (pipenv install pytest).

Additionally, if you do not use any environments:
global install: pip install --force-reinstall pytest==5.0.1
user install: pip install --user --force-reinstall pytest==5.0.1

@krazyace78, thanks for letting us know about this.  It looks like pytest 5.1.0 changed something in their XML output.  We'll get this fixed as soon as we can.

Also need to uninstall and reinstall pytest-cov after downgrading

Prescribed solution

Check https://github.com/Microsoft/vscode-python/blob/566d759340d527a0f5b628bcca95d1eecaf0c698/src/client/testing/common/xUnitParser.ts#L65
If parserResult does not have an attribute testsuite, look for testsuites. The new line would be
const testSuiteResult: TestSuiteResult = parserResult.testsuites[0];

The suggestion of @Marsfan was great but while I am debugging I faced with the following error after the last instruction, my assertion
self.assertEqual(response.status_code, 200)
The error I got (after the last F10) is:

Could not load source '': Source unavailable.

Downgrading to 5.0.1 fixed my issues with VS Code and PyTest

Downgrading pytest fixed my issues, thanks @Marsfan

Hi all, it's fixed in the insiders version of the extension now. (You can use Switch to insiders weekly command from CmdPalette to download the latest version of the extension)
The fix will be out in the next stable release.


Allow adding read permission to reports in the role screen

Currently the access is given from within the report which sometimes is critical, as we cannot give any user the ability to update reports as they could mess up with the report