Fully support Active Record 6.1

As @Kuchick mentioned #48, the current code doesn't support Active Record 6.1. The main change is about retrieving the database config, while being backward compatible (related Rails PR - https://github.com/rails/rails/pull/37253).
Also added Rails 6.1 in the CI matrix to be sure that is working as expected.
This is my first attempt to contribute here, so please let me know if you need anything to be adapted :pray:

Hi @dsantosmerino! This looks really good. Thanks for putting this together. I'm not immediately certain why Codecov is complaining about loss of test coverage. Can you see if you can figure that out so we can stay at 100% coverage? Once that's clear I'll be happy to merge and release this!

Hi @dsantosmerino! This looks really good. Thanks for putting this together. I'm not immediately certain why Codecov is complaining about loss of test coverage. Can you see if you can figure that out so we can stay at 100% coverage? Once that's clear I'll be happy to merge and release this!

@dsantosmerino Yo, I found myself with some free time today, and I want to get this merged and released ASAP, so I figured out what was going on with the missing test coverage. Turns out that the refactor exposed missing coverage that was there all along! Before the refactor, all of this was on one line:
models.select(&:connection_pool).detect { |m| m.connection_pool.spec.config[:database] == database_name }

models was always an empty array, though, in the existing tests, so the line was technically covered, but the block was never actually executed. Your refactoring split that block off into a new line and with a new extracted method, and exposed this issue.
This is great! I've written a few tests to resolve this missing coverage, so I'm going to merge this PR, and then push the new tests on top to get back to 100%.
Thanks for your great work here!

@dsantosmerino Yo, I found myself with some free time today, and I want to get this merged and released ASAP, so I figured out what was going on with the missing test coverage. Turns out that the refactor exposed missing coverage that was there all along! Before the refactor, all of this was on one line:
models.select(&:connection_pool).detect { |m| m.connection_pool.spec.config[:database] == database_name }

models was always an empty array, though, in the existing tests, so the line was technically covered, but the block was never actually executed. Your refactoring split that block off into a new line and with a new extracted method, and exposed this issue.
This is great! I've written a few tests to resolve this missing coverage, so I'm going to merge this PR, and then push the new tests on top to get back to 100%.
Thanks for your great work here!

@dsantosmerino and @botandrose  thanks!
@botandrose Can these changes be added to database_cleaner v1.8 (as 1.8.6) to have Rails 6.1 support because of 2.0 version is in beta?

@dsantosmerino and @botandrose  thanks!
@botandrose Can these changes be added to database_cleaner v1.8 (as 1.8.6) to have Rails 6.1 support because of 2.0 version is in beta?

Just released v2.0 of all gems!
On Sun, Jan 31, 2021 at 3:17 PM Seryozhka<EMAIL_ADDRESS>wrote:

@dsantosmerino https://github.com/dsantosmerino and @botandrose
https://github.com/botandrose thanks!
@botandrose https://github.com/botandrose Can these changes be added to
database_cleaner v1.8 (as 1.8.6) to have Rails 6.1 support because of 2.0
version is in beta?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/DatabaseCleaner/database_cleaner-active_record/pull/50#issuecomment-770469461,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAEH376NCS4EIZPA3SFR3DS4XQILANCNFSM4WWTAV2A
.

Just released v2.0 of all gems!
On Sun, Jan 31, 2021 at 3:17 PM Seryozhka<EMAIL_ADDRESS>wrote:

@dsantosmerino https://github.com/dsantosmerino and @botandrose
https://github.com/botandrose thanks!
@botandrose https://github.com/botandrose Can these changes be added to
database_cleaner v1.8 (as 1.8.6) to have Rails 6.1 support because of 2.0
version is in beta?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/DatabaseCleaner/database_cleaner-active_record/pull/50#issuecomment-770469461,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAEH376NCS4EIZPA3SFR3DS4XQILANCNFSM4WWTAV2A
.


issue resolve test

Some badge fixes and build checks

Coverage remained the same at 0.0% when pulling ea8809a67a0dce6e4109eafbe466715ce4f43023 on dev into affe7b9f759a634ff696bc509045e06252fa1770 on master.

Coverage remained the same at 0.0% when pulling 0d3cd0c4e324b5d5bfe5b07b41e6670f5fdf8596 on dev into affe7b9f759a634ff696bc509045e06252fa1770 on master.

Coverage remained the same at 0.0% when pulling 8f2f1dcc3a908cb057f4fef88d92390c6cc95ddd on dev into affe7b9f759a634ff696bc509045e06252fa1770 on master.

Coverage remained the same at 0.0% when pulling 3c3c98057397929a83a48d74505b634851f1ede7 on dev into affe7b9f759a634ff696bc509045e06252fa1770 on master.

Coverage remained the same at 0.0% when pulling 894d23d400b60dc7097b5fb93b5f3a2f3b1ed8e8 on dev into affe7b9f759a634ff696bc509045e06252fa1770 on master.


Is there a way to keep text showing while changing images?

The text seems to "refresh" when scrolling through the pics

To be honest, there's not an easy way to disable that animation, it's a javascript problem and I must admit that I'm not that good yet.


Onboard dependabot workflows

Generated by https://github.com/adevinta/vulcan-cicd/actions/runs/6183680487

Updated by https://github.com/adevinta/vulcan-cicd/actions/runs/6185343677

Updated by https://github.com/adevinta/vulcan-cicd/actions/runs/6185382510


Migrate to TypeScript

Problem

This tool was built in JavaScript to be a simplest example of Editor.js Tools API usage. Right now further enhancements requires more modern stack.
Importing this package in TS project leads a TS error: https://github.com/codex-team/editor.js/issues/2143

Task
We need to migrate this project to TypeScript and provide type declarations. Make sure types for the plugin are available when using it in Typescript project with Editor.js

Assigned to @Prakhar-FF13


Visibility of Sub-Heading and button on Home Page

Problem

Solution
I want to fix the visibility of the sub heading and also the button on the home page
Request
I am a GSSOC contributor and please assign me this issue

I  want to work on this issue please assign me this issue under GSSOC'24

@solanki505 Being a contributor, I have first opened this issue and I request to assign it to me
so you can check the website again thoroughly and you can open your own issues :)

please assign me this task under gssoc24


Release guidelines

Hi BIDS Community!
I noticed that we do not have a document outlining release guidelines. This would be good to document and make clear for when a release is ready to be processed. I have started a google document to capture these guidelines. Love to get thoughts/feedback on it!
We are likely due for a release soon, but good to document this decision-making process to make it more clear
Thank you!

Thanks for raising this @franklin-feingold - I agree that we should do a minor release soon, mainly to move all infrastructural changes of the Mkdocs setup from latest to stable and hence make these improvements visible. (clickable links, logos, panel to dynamically select versions, typo and link fixes, ... and numerous other improvements)

tagging a related issue: https://github.com/bids-standard/bids-specification/issues/199

+1 on these guidelines. Thanks, @franklin-feingold ! Can we also make it clear how the decision to release relates to our decision-making document ? Since they're likely to interact !

Regarding release dates - we have this documented in the Release_Protocol step 6
I agree they are likely to interact, but the decision-making kicks in once the decision to release has been established. The rules of decision-making govern the mechanism of doing the release (i.e. waiting 5 business days to merge), but the guidelines are meant to give structure on when to release. Perhaps providing this distinction in the document may help give clarity? I can add this section in. wdyt?

That would be helpful, I think ! Though I have one more question :

the decision-making kicks in once the decision to release has been established. The rules of decision-making govern the mechanism of doing the release (i.e. waiting 5 business days to merge), but the guidelines are meant to give structure on when to release

I think my confusion here comes in mostly for the patch releases, since the guidelines recognize that there's some ambiguity about when smaller changes will add up to a release. Maybe we could specify that it's a judgement call that falls to a maintainer?

Maybe we could specify that it's a judgement call that falls to a maintainer?

:+1:

there's some ambiguity about when smaller changes will add up to a release.

As the start of a guideline, additions that seem to be motivated by a use case should probably trigger a timer, formally or informally. If somebody needs to augment the spec in order to make their data conformant, provide a name for metadata required by their app, or refine the semantics of pybids or some other parser, then I think we have some obligation to release relatively promptly (<2 months).
Should probably write this suggestion into the doc, but just to throw it out here while I'm thinking of it.

Both sound good to me!
I have added some text in the release guideline to address when the decision making rules come into effect and what they govern. Also that the judgment for a patch release falls onto the maintainer working group with a 'motivated by use case' example added to the list of actions that can trigger the patch release decision.
I like the idea of giving a timer to the next release. This timer can be set on the readme file and on the website to indicate a release is close to being made.

closed by #267


Add versioning banner

Changes
Display a

purple banner on older version pages

grey banner on v2 pages,

no banner on pages that don't have a v1 equivalent, or are not covered by version control

Feedback: Should use warning icon & grey banner instead of purple banner for old pages

My preference would be something like this. I think it's attention-grabbing enough, and it uses the standard component.


Range Labels don't align when using arcDegreeScale

The range labels don't properly align when you use the custom arcDegreeScale property on a segment. This functionality was introduced in #70

@dakota-kallas oooooooooo good catch, I'll see if I can get this resolved tomorrow

I have a fix incoming that will allow aligning range displays with segments. Updates will be reflected in the README as well for usage.


Brackets Change Colour On Scroll

I just experienced this same issue while using swackets with clojure. I found its related to comments or comment blocks in some way.

Notice how in the screenshots below, text that is commented out is getting highlighted. I think this contributes to the issue.
Before Scrolling:

After Scrolling:

If only I could reliably trigger this, it's like coding in a disco!

Let me know if latest Swackets v0.35 does anything to aide/worsen it, thanks!

@jrattray13 Definitely still happening.

@jrattray13 Yep, still happening for me too I'm afraid.

It seems like it has to do with comments getting interpreted as actual code and messing with the colors

@jrattray13 would a file where this reproducibly occurs help?

this bug is still present. Shame because its really nice.

Yeah it looks like it is choosing colours at random instead of having set colours per depth level.  Like for instance 1st level green, 2nd level yellow, 3rd level orange etc.
Is it only colouring what is visible, or is it doing the whole file?

Still happening and i also want to take the opportunity to say you, thank you for this package.

This is an issue for me as well. Maybe @CaffeinatedTech is onto something, in fact, that is what I suspected before finding this issue.


tf.boolean_mask lack checking for bool arguments

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Y
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 18.04
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: N
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): 2.7.0
Python version: 3.8
Bazel version (if compiling from source): N/A
GCC/Compiler version (if compiling from source):N/A
CUDA/cuDNN version: N/A
GPU model and memory: N/A

Standalone code to reproduce the issue
import tensorflow as tf
tensor = [0,1,2,3]
mask = tf.random.uniform([4], dtype=tf.float64)
tf.boolean_mask(tensor, mask)
# Outputs: <tf.Tensor: shape=(4,), dtype=int32, numpy=array([0, 1, 2, 3], dtype=int32)>

Describe the current behavior
tf.boolean_mask has an argument mask which should be a bool tensor. However, it does not perform any validity checking and can accept a float64 value.
Describe the expected behavior
tf.boolean_mask should check the dtype of input tensor mask.
For example, tf.math.reduce_any would check the first argument and throw an InvalidArgumentError for non-boolean inputs.
import tensorflow as tf
input_tensor = tf.random.uniform([4], dtype=tf.float64)
tf.math.reduce_any(input_tensor) # InvalidArgumentError: cannot compute Any as input #0(zero-based) was expected to be a bool tensor but is a double tensor [Op:Any]

Added a PR #54412 for the fix.

@ArrowIntoTheSky, The issue will move to closed status once the https://github.com/tensorflow/tensorflow/pull/54432 is merged. Thanks!


ensure the socket URL is a string

When I tried to add a custom websocket URL, I ended up seeing this error in my javascript console:
Uncaught SyntaxError: Unexpected token :

when I click through the error, it looks like the websocket URL isn't a string.

I actually found this out when working on #131, but in the interest of simple isolated fixes I pulled it into a separate PR. If you decide to merge #131 right away then this fix doesn't really matter.
/cc @bruce @benwilson512 @tlvenn

Good catch @craig-day , since #131 has been merged, I will close this PR.


chore: Upgrade the git checkout on CI to actions/checkout@v3

Thanks! Didn't know there is a new version)


DJL on Arm

Question
I knew if I waited long enough someone would come up with a Java API/framework to leverage latest and greatest without needing to use python. Thank you!!!
Has any work been done or testing on arm platforms like Jetson Nano, Google Coral or Raspberry PI. Primary use case is running models on the edge and leveraging GPU on Nano, Tensor Flow Light on Coral and CPU on PI.
Going to assume this is JNI under the covers linking to appropriate C libraries and thus a compile/install package needed for each OS/hardware combination.

Thanks! I have built the PyTorch native code including libtorch & JNI on a1 instance (arm) and it works without any problem. I think it should be able to extend to any arm-based edge device like Jetson Nano. I'll switch the labels to "feature request" as we should have tutorial or example of how to deploy the model on edge devices.

Or probably to epand the use cases we may need to consider adding TensorFlow Lite into DJL's family

Hi @willishf I am going to close the issue in favor of #375

I have made reasonably good process on leveraging gstreamer pipeline for
image processing on jetson nano in Java. Nvidia is making a big investment
in DeepStream which is based on gstreamer to stay in gpu pipeline as long
as possible for high FPS from megapixel camera.
Having mxnet model conversion support that runs in gstreamer would solve
many problems related to megapixel camera access and high FPS. DeepStream
is closed source.
DJL via gstreamer would have full control of pipeline running on jetson
nano hardware that is gpu enabled. To run on raspberry pi the gstreamer
pipeline would not have native gpu image conversion tools but would be a
gstreamer raspberry pi equivalent pipeline.
Can do a demo if that would help fill in the details.
On Wed, Feb 17, 2021, 6:37 PM Jake Lee<EMAIL_ADDRESS>wrote:

Hi @willishf https://github.com/willishf I am going to close the issue
in favor of #375 https://github.com/awslabs/djl/issues/375
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/awslabs/djl/issues/195#issuecomment-780925308, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AA653HU3KDRYJTQ4NMUIVMTS7RHMDANCNFSM4SHUC4KA
.

Hi @willishf that's awesome!
What do you mean by Having mxnet model conversion support? If the goal is to run MXNet model on Jetson, I think MXNet python can already do that. We just need to include their native libraries(libmxnet.so) into DJL. Or does it require other integration with gstreamer?

It is my understanding that one of the goals of DJL is being model agnostic
and hiding those implementation details. That was the point I was trying to
make. Having a gstreamer plug in that runs inference on GPU regardless of
framework would be a very nice feature. On embedded systems with hardware
pipelines from camera to GPU you want to avoid touching the image data at
the CPU level for optimal performance. Gstreamer is a C api/library focused
on setting up pipelines that have inputs and outputs. If you can make the
inputs match the outputs and the outputs match the inputs then you can
basically write a pipeline and hand it over to gstreamer and it makes it
happen. You can do just about anything with gstreamer related to video and
audio.
The following pipeline is what I launch in Java to tell gstreamer I want
the NVIDIA supplied camera interface application *nvarguscamerasrc *to
connect to the camera with attributes of memory type, resolution and
format. The second step is *queue *that the camera only supports 30fps but
I can only process 5 fps so don't buffer and drop the oldest frames because
I only want to see the most recent image. The *nvvidconv *application runs
on the GPU and can take images directly from camera and is the swiss army
knife of format, size, cropping, resolution, rotation all done on GPU.
The *identity
*step is where I hook into the pipeline and register a method to be called
for each new image, I process the image and then put it back in the
pipeline for the next step. The *nveglglessink *step runs GPU application
provided by NVIDIA to display the image. I could add in a h264. h265, V8
etc encoding step that if GPU aware would run on GPU. You can then add a
h264 payload wrapper step and then write to storage or stream on the
internet.
gstreamerPipeLine = "nvarguscamerasrc ! video/x-raw(memory:NVMM),
width=1640, height=1232, format=NV12 ! queue max-size-buffers=1
leaky=downstream ! nvvidconv ! video/x-raw, width=1640, height=1232,
format=RGBA ! identity name=identity ! nveglglessink -e"
From a deep learning perspective and what DeepStream does is to add an
inference engine with a specific supported model and run on GPU directly.
If all of your steps run on GPU you can take advantage of the hardware
pipeline for performance. I would then hook the Java application into the
step after the gstreamer inference engine and consume meta data via call
back and only touch the image data if needed. Gstreamer is also supported
on Google Coral but using google supplied applications that know how to
leverage the hardware pipeline. This also works on Linux with the latest
and greatest NVIDIA GPU cards and windows as well. The gstreamer pipeline
has a large number of tools in the tool box that run on windows and Linux
usually by the same attribute description. NVIDIA provides tools that will
only work on Linux as an example.  Using the GPU in Gstreamer for real time
h264/h265 encoding has been around for awhile. Using gstreamer to do
inference on GPU is the way to go for performance.
On Thu, Feb 18, 2021 at 12:43 PM Jake Lee<EMAIL_ADDRESS>wrote:

Hi @willishf https://github.com/willishf that's awesome!
What do you mean by Having mxnet model conversion support? If the goal is
to run MXNet model on Jetson, I think MXNet python can already do that. We
just need to include their native libraries(libmxnet.so) into DJL. Or does
it require other integration with gstreamer?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/awslabs/djl/issues/195#issuecomment-781519822, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AA653HT7HYWEX2TFVB7X2SDS7VGVHANCNFSM4SHUC4KA
.


java.lang.UnsupportedOperationException: direct buffer

Hi,
I'm having the following problem on netty 4.1.0.CR7:
java.lang.UnsupportedOperationException: direct buffer
at io.netty.buffer.PooledUnsafeDirectByteBuf.array(PooledUnsafeDirectByteBuf.java:343)
at io.netty.buffer.SwappedByteBuf.array(SwappedByteBuf.java:916)
With this code (works fine on other versions):
return new String(msg.readBytes(strLength).array());
msg is a ByteBuf

That is because its a direct buffer and so hasArray() returns false. This is expected as stated in the javadocs

I upgrade netty-all-4.0.36.Final to 4.1.0.Final so that meet the problem.

@normanmaurer How do i get a byte[] from a ByteBuffer now since array(); gives this error?
Thanks

The ByteBuf interface offers readBytes(byte[] dst); and getBytes(int index, byte[] dst); which will copy the data to a byte[] if that is what you need. See the javadocs in ByteBuf for more info.

If you use kotlin you can make an extension and use that instead
fun ByteBuf.toByteArraySafe(): ByteArray {
    if (this.hasArray()) {
        return this.array()
    }

    val bytes = ByteArray(this.readableBytes())
    this.getBytes(this.readerIndex(), bytes)

    return bytes
}

Hi, you can use that instead
new String(ByteBufUtil.getBytes(buf), Charset.forName("UTF-8"))


benchmarks: Rename 2 benchmarks which were fixed recently.

So that we don't compare with the (wrong) baseline

@swift-ci smoke test and merge


Revert "make isOpen a computed property"

Reverts apple/swift-nio#123
/cc @toffaletti
I just noticed that #123 was not actually SemVer patch, but was SemVer major, because it changed the behaviour of a public initializer of public class. We should back this out because we don't need that change right this second.
@toffaletti, I'd like to propose that you re-open that PR and that we split it into two parts. The first part will be the change to BaseSocket, and the test changes. The second part would be the change to FileRegion. That will allow us to keep the FileRegion change easy to merge for 2.0, but get the majority of the hairy changes out of the way.
While we're here, @weissi suggested a nice improvement to the test changes: rather than change everything to use named pipes or socketpairs, why not use an arbitrary somewhat large integer (0xBADF, for example) that is highly unlikely to be a valid file descriptor. That will keep the current semantic of using -1.

@toffaletti please do as @Lukasa suggested. Thanks again :)

@Lukasa I don't think I changed FileRegion so just to make sure we're on the same page:
You want patch one to be everything minus the precondition(descriptor >= 0, "invalid file descriptor") checks? And patch two for SemVer major change to just be precondition(descriptor >= 0, "invalid file descriptor")?

@toffaletti I think he meant FileHandle.

Sorry, I meant FileHandle. And @toffaletti, I think we need to just not change that object at all, because without the precondition we have still dramatically changed the behaviour of the object.

I would argue if anyone was depending on the behavior of being able to use an invalid file descriptor they are probably hiding a serious bug, and without calling takeDescriptorOwnership to "leak" the descriptor like the tests were doing, they'd already encounter either a throw in close() or the precondition in deinit.

@toffaletti That's neither here nor there. Our own tests demonstrated a possible purpose for doing this, and while it's clearly the case that there's no utility in doing this in production code, in test code there were possible values. Given that we were doing it (in code others are likely to use as examples), we should be cautious. Code that previously "worked" (even if it didn't do anything) now explodes your process, and we should be defensive against that case.

I think #136 is what you're asking for then?
We can agree to disagree, but your position that the test code might be teaching people to pass invalid file descriptors to a class that is presumably a safe wrapper around a file descriptor suggests a bug that needs fixing. The documentation says:

A FileHandle is a handle to an open file.

But clearly that isn't the case. In fact, the test code was very confusing to me when I encountered errors after making the change because it wasn't clear to me that the tests never actually used the file descriptor and it was OK to just pass anything despite what seemed logical to me, which is why I opted for using pipes and socketpair.

I disagree. While I agree that passing invalid FDs to FileHandle behaves strangely, the truth of the fact was that it was a thing that you could do, and that behaved in an entirely predictable way. We did not document a requirement on this API and we did not enforce a requirement on this API. More importantly, if someone literally copied code from our tests, that code will break if we add the precondition or if we change the behaviour of the object.
"We didn't intend this behaviour" is a very weak argument for downgrading something from SemVer Major to SemVer Patch. There are definitely times when that's acceptable, particularly if the behaviour leads to a severe bug (e.g. protocol RFC violation, memory mismanagement, etc.). In this case, we aren't trying to fix a bug, we're trying to save a word of memory. That's a laudable goal, but it's not urgent; the NIO codebase is not dramatically improved by putting the patch in now instead of in 2.0.

Put another way, @normanmaurer, not having the precondition there wasn't a coding error, because we actively used that functionality in our tests. It wasn't an oversight, we didn't miss it, if the precondition was in there the entire test suite would have had to be rewritten (which is why @toffaletti's patch rewrote the test suite).


refactor: migrates viewing rooms to v3

Just opening a draft; will fill in a few gaps and post screen captures tomorrow.

💥

I'm gonna go ahead and merge. I suspect there will be some follow up design Q/A; but best get this to staging — it's an improvement at least.


Claims to be used in oAuth Access tokens

Problem description
There have been several discussion rounds on the format of the scope parameter in the access token request. The agreement for the short term solution describes a proprietary format and has been included in
(1) CAMARA-API-access-and-user-consent-management.md (IdentityAndConsentManagement/documentation/CAMARA-API-access-and-user-consent.md at main · camaraproject/IdentityAndConsentManagement (github.com)).
Another document describes the generic handling of access tokens. This is
(2) CAMARA-AuthN-AuthZ-Concept.md document (https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-AuthN-AuthZ-Concept.md ).
Here it is stated that: Access tokens should be signed and encoded as JWT (Json Web Token), with the bearer type specified.
In the very same document it is stated that the resulting token must be checked (and therefore contain claims) on:
•	Expiry of the token (exp_claim)
•	Issuer recognized as a trusted issuer (iss_claim)
•	Consumer whitelisted in ACL list (azp_claim)
However, the format of scope claim as consequence of description in (1) for access and consent management and the handling of purpose are not documented. This needs to be agreed urgently, since the service implementations usually evaluate the content of the access token and therefore must know what to expect.
Even though the authorization request uses a custom format for the scope parameter (and includes the purpose in it), this is not allowed in the resulting access token. According to the standard RFC 8693: OAuth 2.0 Token Exchange (rfc-editor.org), 4.2, the value of the scope claim is a JSON string containing a space-separated list of scopes associated with the token, in the format described in Section 3.3 of [RFC6749].
From RFC 6749: The value of the scope parameter is expressed as a list of space-
delimited, case-sensitive strings.  The strings are defined by the
authorization server.  If the value contains multiple space-delimited
strings, their order does not matter, and each string adds an
additional access range to the requested scope.
Expected action
Thus the scope claim in the access token must have the exact same values as the scope strings defined in the API definition registered with the authorization server.
In case the API name as “bundle scope” is used in the scope request, this bundle scope must be extended to the individual list of scopes as contained in the API definition.
The purpose parameter should be included in the access token as well, but cannot be conveyed in the scope claim of the access token without breaking the standard RFC 8693. Thus the purpose parameter should be included in the access token in a separate claim.
Our proposal is to use “crn” claim describing the call reason. This is a public claim specified by JSON Web Token (JWT) (iana.org). It has been introduced with RFC-ietf-stir-passport-rcd-26 (draft-ietf-stir-passport-rcd-26 - PASSporT Extension for Rich Call Data).
Alternatively, a new claim, e.g. called “purpose” could be requested.
Additional context and example
An example for an access token generated on an authorize request for SIM-SwaP API would then look like:
GET /authorize?response_type=code&client_id=myApp&client_secret=0xahh23457& scope=“dpv:fraud-prevention#check-sim-swap” & redirect_url=aggregator_callback
{
"iss": https://mycsp.auth0.com/,
"sub": "+46772334567",
"aud": " https://mycsp.com/APIexposureService ",
"exp":<PHONE_NUMBER>,
"iat":<PHONE_NUMBER>,
“client_id”:0x3445a2,
“azp”:”coolApp”,
"scope": " check-sim-swap ",
"crn": " dpv:fraud-prevention "
}
When the request contains the API name instead of a single technical scope (as exemplified below), then the generated access token must contain the list of data scopes provided by the API.
GET /authorize?response_type=code&client_id=myApp&client_secret=0xahh23457& scope=“dpv:fraud-prevention#sim-swap” & redirect_url=aggregator_callback
{
"iss": https://mycsp.auth0.com/,
"sub": "+46772334567",
"aud": " https://mycsp.com/APIexposureService ",
"exp":<PHONE_NUMBER>,
"iat":<PHONE_NUMBER>,
“client_id”:0x3445a2,
“azp”:”coolApp”,
"scope": "check-sim-swap retrieve-sim-swap-date",
"crn": " dpv:fraud-prevention "
}
Additional context

Hi @Elisabeth-Ericsson !
Thanks for this issue - I have an impression that we're missing a significant piece of flow in Camara, which is Access Token issuance.
Knowing that Camara follows the OpenID Connect framework, we should rather discuss ID Tokens, as JWTs that handle claims, NOT Access Tokens, as these point towards using OAUTH2.0 inside Camara, which is not true.
Therefore, Camara has to be very precise about the Authorization/Authentication framework:

if Camara uses OpenID Connect - ID Tokens are the perfect place to add claims (additional as well, as mentioned in OpenID Connect specification)
if Camara uses the OAUTH2.0 Authorization code grant - Access Tokens represented as JWT is a way to go, but then we need to update all specs (delete openId security scheme and change to oauth2.0)

I think that OpenID Connect is a better choice, due to telco characteristics (there is almost always data resource - telco services subscriber - behind API calls, that requires some kind of authentication/consent).

Why not return the "unbundled" scope in "scope" in the access token e.g.
{
"iss": https://mycsp.auth0.com/,
"sub": "+46772334567",
"aud": " https://mycsp.com/APIexposureService ",
"exp":<PHONE_NUMBER>,
"iat":<PHONE_NUMBER>,
“client_id”:0x3445a2,
“azp”:”coolApp”,
"scope": "dpv:fraud-prevention#check-sim-swap dpv:fraud-prevention#retrieve-sim-swap-date"
}
We would standardize all the scopes for all purposes and then there is no need to add a new field.
Resource servers can have a standard implementation for scope handling by continuing to handle static lists of all supported scopes and there is no need to semantic handling of scopes in the RS.
I would like that Camara stays with standard RS implementations. Scopes are proprietary by definition, except the standard scopes defined in OIDC, so we can define whatever we want. But comparing a requested static string to an allowed static string is the "normal" way this is implemented. Semantic handling adds a layer of complexity that gets us into vendor lock-in which Camara should avoid. Adding new fields locks Camara into specific implementations of AZ and RS. I think we should avoid that lock-in.
Also, I would like that Camara uses static scopes in the AZ implementation. Bundled scopes need special processing in the AZ and then again we have a vendor lock-in. Maybe bundled scopes were discussed and decides elsewhere in the past.
A need for proprietary implementations kill projects. Camara should not go there without a good reason.
Maybe there are other reasons to add "purpose" or "reason" to access token. If it is only to avoid long lists of long scopes, I would not go there.

Hi Axel,
I strongly suggest not to do this.
It will be a nightmare, coming with a huge list of purpose  & scope combinations.
The scopes supported by a Camara API are included in the definition. If you want to combine them with all possible purposes, (https://w3c.github.io/dpv/dpv/#vocab-purpose), you will get 78 x data scope combinations.
Our design should be future proof. There might be new purpose values coming up, but this is not the only reason. There is much much more.
There are various reasons to make sure that scopes and purposes are decoupled and properly listed in the claim section of the token.
0) asking the user for consent becomes unmanageble, since you need to present

combining purpose and scope in a new scope string will allow to include multiple purpose and scope combinations in the access token request. If you then just include the result list in the access token, it might be that you get a mix of purposes again, e.g.  dpv:service-provisioning#qod-sessions-write , dpv:Advertising#qod-sessions-read. Then you have to specify the actual purpose again when calling the API, such that the API knows the permitted data scopes. As a consequence we are back to custom format and need to change.
the access token content is evaluated by the API implementation. Instead of building the need to decompose purpose and data scopes, the list of data scopes shall be separated out in a clean way.
the purpose for calling an API must be available at API invocation to log it in the API report. This is a critical information to find the pricing information at charging time.
the invocation protocols should be as close to the standards as possible. In the standard, it is clearly stated that the scope is the same scope registered on the authorization server. It is highly questionable whether  the huge number originating from all potential scope and purpose combinations can be supported
the API exposure platform at CSPs will have Camara APIs and most probably also (not yet Camara) APIs exposed. The invocation flows, the way of how scopes are registered etc should be the same. Otherwise and aggregator will have to build lots of different token request flows.

Regarding your statement about bundle scopes:
Using "bundle" scopes is a decision on a short term approach. The discussion was driven by Telefonica, Orange and DT and accepted by the other participants engaging in the discussion. Please see issue #32.
I suggest to not reopen this discussion again. Instead we can take the discussion on the ability to pass a scope list in issue #87.

@ DT-DawidWroblewski: I agree, I have changed the title of the issue to be more generic. We have to discuss the claims included in the generated JWT token.

@DT-DawidWroblewski

Knowing that Camara follows the OpenID Connect framework, we should rather discuss ID Tokens, as JWTs that handle claims, NOT Access Tokens, as these point towards using OAUTH2.0 inside Camara, which is not true.

Referring to CAMARA-AuthN-AuthZ-Concept.md, the section under "Access tokens, ID tokens and refresh tokens". Access Tokens can be encoded as JWT. Does this section need updating?

Access tokens, ID tokens and refresh tokens
Access Tokens: An access token represents the delegated permissions that the resource owner (the user) has given the client application. An access token could contain information about the user who delegated permission, but it does not actually represent the user. An access token also does not represent or give any indication of a user having authenticated. Access tokens should be signed and encoded as JWT (Json Web Token), with the bearer type specified. As access token is intended for a protected resource, the protected resource should be responsible for understanding and validating the token.
ID Tokens: An ID token contains the identity of the resource owner. It describes the authentication event that took place at the identity provider. It contains information such as how and when the user last authenticated. It is always signed and encoded as a JWT.
Refresh tokens: A refresh token is used to reauthorize the granted access by allowing the client application to obtain an access token without the user credentials. The refresh token would be used when the previous access token expires and is no longer valid. An access token generally has a short lifespan to limit the damage that can be done if it were compromised. A refresh token helps improve the experience of the API consumers by not asking them for credentials on a too frequent basis. Protocol Flow
Please note that the ID token mentioned above is not a part of Oauth2 specification. It is defined in the OpenID connect (OIDC) specification described later in the document.

Having been involved in authorization code flow implementation for a CAMARA API, I'd like to add some comments for those that might be confused by some of the above discussion:

The /authorize endpoint does not return a token of any sort. Rather it returns an authorisation code, which contains no embedded information. The authorization code is then swapped for an Access Token and an ID Token via the POST /token endpoint.
The ID Token is only returned because the OpenID Connect specification says it is mandatory. But it is not required to access the service API endpoint, and can be ignored by the API consumer. Only the Access Token is required to access the service API endpoint.
Both the Access Token and ID Token MUST NOT contain the end user identity, because this will not necessarily be known to the API consumer, who only requires the information that will be returned by the service API endpoint. Note that the CIBA authorisation flow tokens can contain the login_hint provided by the API consumer in the bc-authorize call, because this information is already known to them.

From Telefonica’s point of view, we do not need and must not standardize the claims or fields of an access_token, because the definition of an access token is an opaque value in the OAuth specs.
The way the implementation of an API can check if an access token is valid, is an internal implementation detail of each solution (e.g. you can implement the access_token system using a JWT or using a random unique value string keeping the data associated to the generated access_token in your database)
We only can talk about data associated internally to an access_token, but that’s still internal to the implementation. The internal details of the API and the OAuth Server implementation are out of the scope of CAMARA. You can decide to use one or the other system because both have their pros and cons.
Regarding the way an application can see the scopes or purposes the access_token has granted is specified in OAuth 2.0 specs (https://datatracker.ietf.org/doc/html/rfc6749#section-5.1).
The response to the token endpoint where the APP receives the access_token field can also include a scope field. This scope field is mandatory if the scope parameter requested by the APP is different to the granted scope, and you can always include the scope field in the response, even if it's the same. The scopes in CAMARA have been defined with this format:
<purpose>#<technical-scope>
But from the technical point of view, in the OAuth Spec and its grant type endpoints, that's just a scope (a string the APP can include in the authorization request inside a list of strings separated by one space).
So, if the APP asks for <purpose>#<technical_scope> you can include it in the token endpoint response if granted. As this scope can be resolved into a list of additional scopes, they would also be included separated by a space in addition to the requested one.
Example
The application requests a scope with the purpose and technical scope format:
dpv:FraudPrevention#check-sim-swap
The response to the token endpoint would be following:
{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"bearer",
  "expires_in":3600,
  "scope":"dpv:FraudPrevention#check-sim-swap check-sim-swap retrieve-sim-swap-date"
}

The APP can see that dpv:FraudPrevention#check-sim-swap was granted, and also the two additional scopes check-sim-swap and retrieve-sim-swap-date associated to it.
dpv:FraudPrevention#check-sim-swap:
The scope requested by the APP, confirming that it was granted. The scope is exactly the same string requested by the APP, complying with the OAuth2 spec. And this scope is using the agreed format <purpose>#<tenchinal_scope> which includes the purpose.
check-sim-swap:
Additional scope granted when dpv:FraudPrevention#check-sim-swap is granted.
retrieve-sim-swap-date:
Additional scope granted when dpv:FraudPrevention#check-sim-swap is granted.

Hi!
@nitroduna makes sense, but then we entering a "grey zone" for CIBA spec, as it is designed for OpenID Connect NOT OAUTH2.0:

The behaviour when the openid scope value is not present is left unspecified by this document, thus allowing for the potential definition of the behaviour in a non-OpenID context, such as an OAuth authorization flow.

CIBA Authentication Request
so either we create a new OIDC CIBA profile, which explains/defines how to use OAUTH2.0 code flow in the context of CIBA, or we leave openid and we comply with the existing standard.
Having MNO characteristics in mind (i.e. subscriber authentication, consent acquisition if relevant), OpenID makes more sense (making Mobile Connect OIDC CIBA profile a complete solution for us).

Hi Axel, I strongly suggest not to do this. It will be a nightmare, coming with a huge list of purpose & scope combinations. The scopes supported by a Camara API are included in the definition. If you want to combine them with all possible purposes, (https://w3c.github.io/dpv/dpv/#vocab-purpose), you will get 78 x data scope combinations. Our design should be future proof. There might be new purpose values coming up, but this is not the only reason. There is much much more.
There are various reasons to make sure that scopes and purposes are decoupled and properly listed in the claim section of the token. 0) asking the user for consent becomes unmanageble, since you need to present
1. combining purpose and scope in a new scope string will allow to include multiple purpose and scope combinations in the access token request. If you then just include the result list in the access token, it might be that you get a mix of purposes again, e.g.  dpv:service-provisioning#qod-sessions-write , dpv:Advertising#qod-sessions-read. Then you have to specify the actual purpose again when calling the API, such that the API knows the permitted data scopes. As a consequence we are back to custom format and need to change.

2. the access token content is evaluated by the API implementation. Instead of building the need to decompose purpose and data scopes, the list of data scopes shall be separated out in a clean way.

3. the purpose for calling an API must be available at API invocation to log it in the API report. This is a critical information to find the pricing information at charging time.

4. the invocation protocols should be as close to the standards as possible. In the standard, it is clearly stated that the scope is the same scope registered on the authorization server. It is highly questionable whether  the huge number originating from all potential scope and purpose combinations can be supported

5. the API exposure platform at CSPs will have Camara APIs and most probably also (not yet Camara) APIs exposed. The invocation flows, the way of how scopes are registered etc should be the same. Otherwise and aggregator will have to build lots of different token request flows.

Regarding your statement about bundle scopes: Using "bundle" scopes is a decision on a short term approach. The discussion was driven by Telefonica, Orange and DT and accepted by the other participants engaging in the discussion. Please see issue #32. I suggest to not reopen this discussion again. Instead we can take the discussion on the ability to pass a scope list in issue #87.

I do not think that all terms from https://w3c.github.io/dpv/dpv/#vocab-purpose are applicable in Camara. Each Camara API has a small subset of purposes for which this API can be used.
The openid and oauth2 standard grant access based on scope. If we invent something new then we move away from standard AZ implementations and relying party implementation.
The cost for proprietary AZ and RPs is high and it makes it harder for us to switch vendors.

@nitroduna: Hi Pedro, some input on yesterday's discussion.
In the Camara documentation [https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-AuthN-AuthZ-Concept.md], it is explicitly stated that JWT format has to be used for the access token  and identity tokens. It is not the opaque format.
So either we have to change this statement in a version 0.2 of the documentation, or we have to comply to it.
In the latter case - which was my starting point - we need to agree on a JWT token format for the access token and the identity token.
Please check the statement on the id tokens, access tokens and refresh tokens.

@Elisabeth-Ericsson
Yes, I see that document has this paragraph

An access token also does not represent or give any indication of a user having authenticated. Access tokens should be signed and encoded as JWT (Json Web Token), with the bearer type specified

So, the document is wrong and that information should be removed. We think those kind of definitions such as access_token, id_token and others, which are already included in the specs, should not be redefined in our documents.
First of all, our solution is an OAuth2 / OpenID Connect solution, so they are built on top of the two main specifications:

OAuth2: https://datatracker.ietf.org/doc/html/rfc6749
OpenId Connect: https://openid.net/specs/openid-connect-core-1_0.html

The definition of thinks like access_token or id_token is already included on those specs. We should not contradict the specs, just extend them using the custom mechanism that the spec provides or for example specifying that some optional features in CAMARA would be mandatory.
The spec of the access_token that CAMARA should comply is the following: https://datatracker.ietf.org/doc/html/rfc6749#section-1.4
Our specs should have explicit references to the specs on which they are built, and not to replicate or redefine mechanisms and concepts already defined in the base specs. That's the same thing OpenID Connect specification is doing, which references OAuth2 because it's a spec built on top of OAuth2. We should do de same.
Anyway, I'm told that document will be removed in v0.2. It seems the document doesn't represent any agreement. It's a document with inherited recommendations that was used as first steps. So, it doesn't contains any agreement and it will be removed, if my information is correct.
Some technical details
According to this spec extracted from https://datatracker.ietf.org/doc/html/rfc6749#section-1.4 the access_token is an value opaque to the client.

Access tokens are credentials used to access protected resources.  An
access token is a string representing an authorization issued to the
client.  The string is usually opaque to the client.  Tokens
represent specific scopes and durations of access, granted by the
resource owner, and enforced by the resource server and authorization
server.

It's true that when you have to implement a system with APIs protected with your own OAuth server, you can mainly adopt two approaches: self-contained access_token or stored access_tokens.
Both of the two solutions have very important pros and cons, but they are related to the internal code of your system and they are hidden. That considerations can affect to the security of the solution and the performance. Neither of them are better than the other, and the reasons you can find are very debatable.
If you implement an OAuth system you have to implement two main components:

The component that implement the OAuth2 endpoints.
The component that protect your APIs with the access_token.

So the requirements for access_token are internal for the system. The developer only have to coordinate the implementation of those two components, so that the mechanism used by the first to generate tokens can be used by the second to validate them and recover all the information required to progress the call to the APIs.
No other external system needs to know how to use that mechanism, and it shouldn't to avoid security issues.
Deciding which mechanism to use and what data to associate with the access token is a developer decision. The two components that need to known that mechanisms are internal to the implementation. APPs using the APIs doesn't need to know that information.
If a developer decides to implement a self-contained solution they can use any other kind of codification and not only JWT, that's another internal implementation decision.
We can see another important defect of what was written in that document:

Access tokens should be signed and encoded as JWT (Json Web Token)

That introduces a potential security problem.
If you generate your self-contained access_token just using JWS (singed JWT), the APP can decode the token and see all the information used by the internal implementation of the OAuth Server.
That is in most of the cases very confidential information which can even contains personal information.
So if you want to use self-contained tokens and you want to use JWT, at least you must use JWE (Encrypted JWT) using a highly protected encryption key that only your system can know about (a problem not found in the stored access-tokens solution).

@nitroduna and @jpengar:
I have done some investigations on implications on option a) using an opaque access token/ identity token and option b) using self contained access/identity token in jwt format and want to summarize the outcome below (including pro's and cons) for subsequent discussion in the work group.
The most important conclusion from this investigation is that there is impact on the L1 service implementation of each L1 service, which needs to evaluate the scope contained in the token and act accordingly.  However the methods of evaluation are different depending on option a) (opaque token) or b) (jwt format). If option a) or b) are the CSPs decision, then an L1 service must be prepared for both options and allow integration to any authorization server in case of a).
Details on option A- opaque token:

A1)  The response to the token request (access/id token) contains an opaque token, which is a reference to a token structure in the authZ server.
A2) The response to the token request (access/id token) must also contain the scope.  Assumption is that the scope parameter has the format 'dpv:<w3c-purpose value>#<requested technical scope> scope1 scope 2 , listing all scopes granted (including expansion of the bundle scope).
A3) The opaque token is sent on API invocation from API invoker to CSP' exposure platform and forwarded to the API by the gateway. Optionally the gateway validates the token with the authZ server.
A4) The L1 API must call token introspection API from authZ server to understand the content of the access or id token. This means that an L1 service must contact the AuthZ server at runtime every time an API gets called to access end point for token inspection.
A5) The response of the API is a list of key value pairs, one of them being the "scope" key.
A6) The format of the scope key must be specified, current assumption is that it is the same as A2)

Details on option B - self contained token, jwt format
B1)  The response to the token request (access/id token) contains a token in jwt forma. Eventually this token must be encrypted.
B2) The response to the token request (access/id token) must also contain the scope.  Assumption is that the scope parameter has the format 'dpv:<w3c-purpose value>#<requested technical scope> scope1 scope 2 , listing all scopes granted (including expansion of the bundle scope).
B3) The jwt token is sent on API invocation from API invoker to CSP' exposure platform and forwarded to the API by the gateway. Optionally the gateway validates the token with the authZ server. Eventually the token decryption could happen here as well.
B4) The L1 API must expand the access or id token. If the token is encrypted - and decryption did not happen in prior step, then this must happen now. The L1 API logic must contact the authZ server to decrypt. The  resulting token in jwt format contains "scp" claim, indicating the scope. the format of scp could be the list of individual data scopes or the format discussed in A2.
Option b) might have security impacts, if the token is not encrypted.
Independent of the options picked both have impact on the L1 service implementation.
With regards to scope format, we should also acknowledge that Telco operators will expose some proprietary APIS and may b APIS originating from 3GPP (e.g. SEAL) on their platforms. Since we have invented a proprietary scope format, all the other APIs must become aware of this format and the options for sending the information (A or B).

Thanks @Elisabeth-Ericsson. What you say is right.
The point is that there is no need to standarize the access token format, as it's a CSP implementation detail.
Let me try to illustrate it with a picture:

The app request an access_token.
The AuthServer in the CSP side generates an access_token:

{
  "access_token": "SlAV3......kKG83",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "..."
}

Here, the access_token can be an encrypted jwt token, a UUID pointing to a record in a CSP database, etc. but in all cases the app must treat the token as an opaque string.

The app calls an API, sending the token as a request header. The requests reaches the API Gateway in the CSP side which, depending on its implementation, can decrypt and validate a self-contained token, go to a database to check whether the token is valid, pass it to the API backend to handle or whatever mechanism the CSP has in place.

All the logic regarding token processing is an implementation detail, done in the CSP side. The same applies if there is an aggregator between the App and the CSP.
There are some interesting points in this thread that are still not closed, such as the ID Token format (my suggestion is to discuss it as part of https://github.com/camaraproject/IdentityAndConsentManagement/pull/113 or in a dedicated issue) and the evolution of the short-term agreement (https://github.com/camaraproject/IdentityAndConsentManagement/issues/32) regarding on how to send the purpose.

There is no conflict between OIDC and OAuth2 regarding access tokens.
For both specs the format is opaque.
Implementers discovered, that having a recommendation how a self-contained access tokens should look like
https://datatracker.ietf.org/doc/html/rfc9068 was standardized in IETF.
Quoting from rfc9068.

Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner.

I think this applies to Camara and I believe Camara should use rfc9068.
The access token should be encrypted so that for Clients the access token is opaque.
For validation the access token should be signed, so that the access token can be validated without a network call to a token introspection endpoint.
Adding a purpose field to the access token does not violate any standard. And that is true, whether the access token is self-contrained or an index into some database that then contains the purpose field.
I suggest that Camara access tokens are self-contained and that can be validated without a network call back to the issuing AZ.
Regarding scope values, scope values are in all standards involved a space-delimited list of case-sensitive strings.
If scopes are returned in a response then they are again a list of space-delimited strings. There could be more strings in the returned list of strings than in the scope value of the request.
For the standards it does not matter whether each string has some structure. For the standards it is still a string that is compared character by character, and it does not matter for the AZ nor the RS whether there is a colon in the scope.

@Elisabeth-Ericsson I understand what you mean, and I totally agree with that; Implementations APIs protected by access_tokens emitted by an OAuth server need to have some mechanism to decide if that access_token has the necessary permissions to call the API.
But still, we think that’s and shall be internal implementation details of each CSP.
That needs coordination between the OAuth Server implementations and APIs implementations (or the component that protect that APIs implementations such as an API GATEWAY). That can be a very internal mechanism, and even more if the provider of the OAuth Server and the Provider of that APIGW is the same, or it can be some mechanism agreed between them if they’re different providers. But no one outside the CSP need to know about that systems or architectures.
There are lot of systems or architectures to resolve that requirement, regardless of whether the OAuth2 implementation is using self-contained or stored access_tokens, such as:

The OAuth2 CSP can provide private introspection APIs only available to the APIs or to the APIGW in front of the APIs to find the data associated to the access_token.

That case doesn't only apply to stored access_token, but also to self-contained tokens because they’re encrypted and that avoids sharing encryption private keys.

The CSP can provide an API Gateway in front of all APIs to resolve the access_tokens and to provide the needed data to the API implementations. That’s a very common solution. An APIGW checking the access_tokens to allow or deny access and even sending access_token data in HTTP headers to the APIs.
The APIs or the APIGW and the OAuth2 server can share private encryption keys to encrypt and decrypt self-contained tokens (that’s not recommended because the bests solutions automatically rotate encryption keys).
The APIs or the APIGW can have access to the database of stored tokens if implemented by the same provider and deployed in same environments.
Etc.

The important thing is that’s internal details. It's communication between systems owned by the CSP. Their OAuth Server and their APIs. A CSP doesn’t need to know about the system used by another CSP to allow its APIs be called with its own access_tokens.
In fact, you don’t even need to know the internal format used by other CSPs, you can choose the more efficient format for you APIGW implementation.
For example a CSP can decide to parse the formatted scopes such as "dpv:#" with a format defined in its solution and give that information to the APIGW or APIs in separated fields already separated in components such the purpose.

Thank you for all of your comments. To summarize the discussion I want to separate the 1) access token handling from the 2) access token content format discussion.
With regards to 1) (Access token handling) I understand that both methods: opaque access token and encrypted JWT access token must be support.  We need to document both of the methods in https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-AuthN-AuthZ-Concept.md or merge it into https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md.
With regards to 2) content of the generated access token resp access token structure in authZ, I need an urgent clarification and agreement.
Proposal for scope handling is to have the permitted data scopes expanded and separated by blank and exactly in line with the data scopes documented in the API spec.
Proposal for purpose handling is to have a separate access token structure parameter which carries the purpose.

Thank you for all of your comments. To summarize the discussion I want to separate the 1) access token handling from the 2) access token content format discussion. With regards to 1) (Access token handling) I understand that both methods: opaque access token and encrypted JWT access token must be support. We need to document both of the methods in https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-AuthN-AuthZ-Concept.md or merge it into https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md. With regards to 2) content of the generated access token resp access token structure in authZ, I need an urgent clarification and agreement. Proposal for scope handling is to have the permitted data scopes expanded and separated by blank and exactly in line with the data scopes documented in the API spec. Proposal for purpose handling is to have a separate access token structure parameter which carries the purpose.

In my opinion:
For point 1) CAMARA should NOT document anything precisely because it does not standardize the implementation. CAMARA doesn't have to say that JWT approach, database approach or any other solution has to be supported.
For point 2), if you are referring to the /token response, we have already explained Telefonica's position in previous comments (https://github.com/camaraproject/IdentityAndConsentManagement/issues/100#issuecomment-1895152957). The purpose information is already present in the scope list returned, since it contains the scope string requested by the client, which includes the "dpv:xxxxx" format.

My summary and understanding of the above:
OAuth2 states this about access tokens https://datatracker.ietf.org/doc/html/rfc6749#section-1.4

Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server.

AZ and RS MUST have an understanding about the access token because otherwise the RS is not able to validate the access token.

It might be that the AZ has a token introspection endpoint, that returns the access token's content (especially scopes) if it is valid.
It might be that AZ and RS agreed on self-contained tokens and a common jwt format. The RS can descrypte and validate the access token and "see" scope which MUST be part of the accesstoken because otherwise authorization enforcement is not possible.
It might be that the AZ has an token-validation endpoint that only answers valid/invalid.

From enforced by the resource server we conclude that for the cases 1) and 2) the RS knows the scopes because otherwise the RS could not enforce. So, if purpose is encoded in scope then the RS knows purpose.
I assume your (@Elisabeth-Ericsson ) concern is with implementation option 3) because then the RS does not know scope nor purpose, right?
Do current implementations use option 3)?

@AxelNennker: thank you for the detailed analysis. Case 3) is the problem.
In case 1) and 2) the RS knows the scopes.

When following the short term agreement on sending purpose concatenated to the scope, then also the purpose is know.
In the future, when opening up this limitation, and sending purpose in a separate request parameter (as standardized by  openid-connect-4-identity-assurance-1_0-13 ), then the purpose should be in a separate claim (for jwt format, case 2) or a separate attribute (for opaque tokens in case 1)


Fix Spotlight

Refreshing doesn't change the first person card

Probably SSR thing?

Scam, math.random always generating 0 as one number

@shaurya5 so the issue is fixed, but it does give warnings because, CSR is re-rendering the random numbers while SSR isn't

yeah works for now. I'll reopen if there's an issue


Update async-nats

trustification dependabot vulnerability alerts
https://gist.github.com/helio-frota/da4c1c984d12cc458f5c58e8b9201fc6

@dejanb we still can see the warning I think that is because of cyclic dependency with trustification:
Crate:     ed25519-dalek
Version:   1.0.1
Title:     Double Public Key Signing Function Oracle Attack on `ed25519-dalek`
Date:      2022-06-11
ID:        RUSTSEC-2022-0093
URL:       https://rustsec.org/advisories/RUSTSEC-2022-0093
Solution:  Upgrade to >=2
Dependency tree:
ed25519-dalek 1.0.1
└── nkeys 0.2.0
    └── async-nats 0.29.0
        └── guac 0.1.0

├── exporter v0.1.0 (https://github.com/trustification/trustification.git?tag=v0.1.0-nightly.9382a428#9382a428)
│   ├── anyhow v1.0.86
│   ├── clap v4.5.4 (*)
│   ├── futures v0.3.30 (*)
│   ├── guac v0.1.0 (https://github.com/trustification/guac-rs.git?rev=5b8cad8342d42072a72ef4a149348d0d86a84176#5b8cad83)
│   │   ├── anyhow v1.0.86
│   │   ├── async-nats v0.29.0  <----------------------------------------------------
│   │   │   ├── async-nats-tokio-rustls-deps v0.24.0-ALPHA.1

either way we need to fix here first :+1:

Yeah, that makes sense. We need to update traustification as well. Maybe it's time to cut the first "release"?

Unless you want some other chore tasks before like:

update the rust version -- same as trustify ( or 177.2 same as trustification )
update other dependencies

we have breaking changes when updating reqwest ^

good approach +1
I'll take a closer look I remember a good amount of compilation errors etc.

@dejanb I suspect that is messing with the other dependency

https://crates.io/crates/graphql_client/0.14.0/dependencies
maybe better to wait for new graphql_client version , makes sense ?

this is the last outdated all the others got updated by the PR


Finish Adding Fonts / Data

The process of adding a font is in the README:
https://github.com/chriscoyier/coding-fonts#adding-a-font
The list so far...

[x] Fira Code – https://github.com/tonsky/FiraCode
[x] FiraFlott - https://github.com/kosimst/FiraFlott
[x] Operator Mono – https://www.typography.com/fonts/operator/overview
[x] Iosevka – https://github.com/be5invis/Iosevka
[x] SF Mono – https://developer.apple.com/fonts/
[x] Cascadia Code – https://github.com/microsoft/cascadia-code
[x] Ubuntu Mono - https://design.ubuntu.com/font/
[x] Hasklig - https://github.com/i-tu/Hasklig
[x] Source Code Pro – https://fonts.google.com/specimen/Source+Code+Pro
[x] Anonymous Pro - https://www.marksimonson.com/fonts/view/anonymous-pro
[x] Fantasque - https://github.com/belluzj/fantasque-sans
[x] Jetbrains Mono - https://www.jetbrains.com/lp/mono/
[x] Roboto Mono - https://fonts.google.com/specimen/Roboto+Mono
[x] Sudo - https://github.com/jenskutilek/sudo-font
[x] Victor Mono - https://rubjo.github.io/victor-mono/
[x] Monoid - https://github.com/larsenwork/monoid
[x] IBM Plex Mono - https://fonts.google.com/specimen/IBM+Plex+Mono
[x] Menlo - https://en.wikipedia.org/wiki/Menlo_(typeface)
[x] Hack – https://sourcefoundry.org/hack/
[x] Cousine - https://fonts.google.com/specimen/Cousine
[x] Consolas - https://docs.microsoft.com/en-us/typography/font-list/consolas
[x] PT Mono - https://fonts.google.com/specimen/PT+Mono
[x] Droid Sans Mono - https://www.fonts.com/font/ascender/droid-sans-mono?QueryFontType=Web&src=GoogleWebFonts
[ ] Liberation Mono - https://www.fontsquirrel.com/fonts/liberation-mono
[ ] EnvyCode Mono - https://www.fontsquirrel.com/fonts/envy-code-r
[x] Inconsolata - https://fonts.google.com/specimen/Inconsolata
[x] Input – https://input.fontbureau.com/
[x] DejaVu – https://dejavu-fonts.github.io/
[x] Gintronic – https://bboxtype.com/typefaces/Gintronic/#!layout=specimen
[x] Recursive Mono – https://www.recursive.design/
[ ] APL386 Unicode - https://abrudz.github.io/APL386/
[x] MonaLisa – https://monolisa.dev/
[ ] Aglet Mono – https://xyztype.com/fonts/aglet_mono
[ ] PragmataPro – https://fsd.it/shop/fonts/pragmatapro/
[ ] Bitstream Vera Sans Mono - https://www.fontsquirrel.com/fonts/bitstream-vera-sans-mono
[x] SF Mono - https://developer.apple.com/fonts/
[x] Courier Prime - https://fonts.google.com/specimen/Courier+Prime

If any of the above should be removed for good reason, feel free to say why here!
Also, we can mine these lists for any good ones we may have missed:

See if anything good here we missed: https://en.wikipedia.org/wiki/List_of_monospaced_typefaces
See if anything good here we missed: https://www.fontsquirrel.com/fonts/list/classification/monospaced

Very robust site with many more https://www.programmingfonts.org/

More fonts here: https://github.com/powerline/fonts

Hi! I don't have time to add this myself until at least mid-January because of work commitments, but I use and love iA Writer Mono: https://github.com/iaolo/iA-Fonts/tree/master/iA%20Writer%20Mono

Hi!
Thanks to you all for these amazing fonts but I am looking for this color theme that you use in the screenshot of the HTML section can you please tell me this theme name please this theme is so amazing.

I am looking for this color theme that you use

I don't think there is an official home for it, but generally known as "Twilight"

I am looking for this color theme that you use

I don't think there is an official home for it, but generally known as "Twilight"

Hi
Thanks for your contribution, but I think the theme you used in the HTML screenshot is "Palenight" related, so now I switched to the "Palenight" theme. Thanks for your amazing work and efforts on coding fonts.


Modern above-list filtering search UI

In the above situation I want to translate the word "relocation", and I'm sure I had translated it before, I just don't remember what it was. (The last time I translated GCC is already 1 or 2 years ago.)
Since the concordance feature is not implemented yet, there's an alternative feature that would help me in this situation. If there were a text field above the translations list that would filter all the translation lines, I could enter "relocation" there. Then, only the current line and those containing the search terms would be shown. This would allow me to quickly see how I have translated this word before.
The current search dialog is not as helpful because it changes the "current location" in the file, and I can see only one of these messages at a time.

This is desirable on its own (I think it's mentioned in some other issue, but I can't find it right now), but probably comparable to concordance search w.r.t. implementation complexity...

It's related to #463 (and guess who reported it). ;)
I find it surprising that you estimate it to be as complex as the concordance search. I thought it would be simpler because you'd just put some standard UI components together and configure the data binding between them. It seems I don't know wxWidgets well enough to estimate these things.

I might have worded it too strongly. That it is as complex as concordance search is BS, but it is more complex than wiring some components together.


Prisma Migrate generates incorrect sql when chaining different types of table altering operations

Bug description
If you perform two different types of alteration on a table for instance renaming a constraint and altering the data type of a column then prisma migrate dev will generate incorrect sql code.
How to reproduce

Consider the following schema:

model Fruits {
   id Int @id(map:"custom_name")
   name String @db.VarChar
}

edit it in this way :

model Fruits {
   id Int @id()
   name String
}

run prisma migrate dev
you will get the following error

Database error code: 42601

Database error:
ERROR: syntax error at or near ","

This is because the generated sql will look like this:
ALTER TABLE "Fruits" RENAME CONSTRAINT "custom_name" TO "fruits_pkey",
ALTER COLUMN "name" SET DATA TYPE TEXT; -- this should be a separate ALTER TABLE statement --

Expected behavior
the generated sql should look like this :
ALTER TABLE "Fruits" RENAME CONSTRAINT "custom_name" TO "fruits_pkey";
ALTER TABLE "Fruits" ALTER COLUMN "name" SET DATA TYPE TEXT;

Prisma information

// Add your schema.prisma

// Add your code using Prisma Client

Environment & setup

OS: macOS,
Database: PostgreSQL
Node.js version: v20.13.1

Prisma Version
5.14.0

I can confirm the problem
npx prisma migrate dev

Environment variables loaded from prisma/.env
Prisma schema loaded from prisma/schema.prisma
Datasource "db": PostgreSQL database "24331-dev" at "localhost:5432"

✔ Enter a name for the new migration: …
Applying migration `20240529123216_`
Error: P3018

A migration failed to apply. New migrations cannot be applied before the error is recovered from. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve

Migration name:<PHONE_NUMBER>3216_

Database error code: 42601

Database error:
ERROR: syntax error at or near ","

Position:
  0
  1 -- AlterTable
  2 ALTER TABLE "Fruits" RENAME CONSTRAINT "custom_name" TO "Fruits_pkey",

DbError { severity: "ERROR", parsed_severity: Some(Error), code: SqlState(E42601), message: "syntax error at or near \",\"", detail: None, hint: None, position: Some(Original(84)), where_: None, schema: None, table: None, column: None, datatype: None, constraint: None, file: Some("scan.l"), line: Some(1127), routine: Some("scanner_yyerror") }


Wrong namespace in ValidationParserLegacy

I tried to achive the tutorial, but I get the following error :
ContextErrorException in DunglasApiParser.php line 51:
Catchable Fatal Error: Argument 2 passed to     Nelmio\ApiDocBundle\Parser\DunglasApiParser::__construct() must be an instance of Dunglas\ApiBundle\Mapping\ClassMetadataFactoryInterface, instance of Dunglas\ApiBundle\Mapping\Factory\ClassMetadataFactory given, called in /var/www/app/cache/dev/appDevDebugProjectContainer.php on line 2384 and defined
I figure out the namespace in use statement of this file is incorrection :
https://github.com/nelmio/NelmioApiDocBundle/blob/master/Parser/DunglasApiParser.php
Can I make a PR to correct it ?

Ok, I realized version 2 of api-bundle was installed, I ran composer update to fix the issue.


Crash Report

http://pastebin.com/LdxPgadB

You are using a -dev.jar - this only works in a development environment.


ART-1466: Fix Elliott fails to attach RPMs are tagged to released tag…

… out of order
Currently Elliott find unshipped RPMs using the following approach:

Get a list A of latest RPMs with candidate tag from Brew.
Get a list B of latest RPMs with base tag from Brew.
Subtract B from A.

The problem is some RPMs that are latest with the candidate tag are not considered latest with the base tag.
In such case, Elliott attempts to attach shipped RPMs but fails with the following exception:
$ elliott --group openshift-3.11 find-builds -k rpm  --use-default-advisory rpm
2020-01-17 06:35:26,363 INFO Data clone directory already exists, checking commit sha
2020-01-17 06:35:26,843 INFO https://github.com/openshift/ocp-build-data.git is already cloned and latest
2020-01-17 06:35:26,906 INFO Using branch from group.yml: rhaos-3.11-rhel-7
Default advisory detected: 50532
Generating list of rpms: Hold on a moment, fetching Brew builds
Refreshing for tag: rhaos-3.11-rhel-7
Refreshing for tag: rhaos-3.11-rhel-7-candidate
Gathering additional information: Brew buildinfo is required to continue
[**********************]
Refreshing for tag: rhaos-3.11-rhel-8-candidate
Refreshing for tag: rhaos-3.11-rhel-8
Gathering additional information: Brew buildinfo is required to continue
[]
[**********************]

Traceback (most recent call last):
  File "/home/nay/yuxzhu/.local/bin/elliott", line 11, in <module>
    sys.exit(main())
  File "/home/nay/yuxzhu/.local/lib/python3.6/site-packages/elliottlib/cli/__main__.py", line 902, in main
    cli(obj={})
  File "/home/nay/yuxzhu/.local/lib/python3.6/site-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/home/nay/yuxzhu/.local/lib/python3.6/site-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/home/nay/yuxzhu/.local/lib/python3.6/site-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/nay/yuxzhu/.local/lib/python3.6/site-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/nay/yuxzhu/.local/lib/python3.6/site-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/home/nay/yuxzhu/.local/lib/python3.6/site-packages/click/decorators.py", line 64, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "/home/nay/yuxzhu/.local/lib/python3.6/site-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/home/nay/yuxzhu/.local/lib/python3.6/site-packages/elliottlib/cli/find_builds_cli.py", line 127, in find_builds_cli
    _attach_to_advisory(unshipped_builds, kind, advisory)
  File "/home/nay/yuxzhu/.local/lib/python3.6/site-packages/elliottlib/cli/find_builds_cli.py", line 249, in _attach_to_advisory
    file_types={build.nvr: [file_type] for build in builds}
  File "/home/nay/yuxzhu/.local/lib/python3.6/site-packages/errata_tool/erratum.py", line 695, in addBuilds
    return self.addBuildsDirect(buildlist, release, **kwargs)
  File "/home/nay/yuxzhu/.local/lib/python3.6/site-packages/errata_tool/erratum.py", line 674, in addBuildsDirect
    self._processResponse(r)
  File "/home/nay/yuxzhu/.local/lib/python3.6/site-packages/errata_tool/connector.py", line 256, in _processResponse
    raise ErrataException(err_msg)
errata_tool.exception.ErrataException: Erratum 50532: Unable to add build 'openshift-monitor-project-lifecycle-3.11.51-2.git.59.7b59e29.el7' which has already been released.

This PR filters shipped builds out of the to-be-attached list.

@shiywang @joepvd @sosiouxme I have addressed the issues. PTAL. Thanks.

I added a commit of my own invention after spending way too long trying to wrap my head around logic. Going to merge now!


Trouble Installing Bob on IBM i

I thought I would leave a comment here just incase anyone else runs across this issue.   I was trying to install Bob and it told me it was not an available package.  "No package Bob available"  Error: Nothing to do
After researching I had to install an update to the yum package itself and also install the package "ca-certificates-mozilla".
After updating yum and install the ca certificate mozilla i was able to install Bob.

Or our prerequisites page we have a section and link showing how to install open source technologies using ACS
https://ibm.github.io/ibmi-bob/#/getting-started/prerequisites?id=install-ibm-i-open-source-technologies


Close VMs on success?

After Karma is stopped the VM's are left open. This is on purpose to allow tests to be re-ran quickly.

Is there any way we can add an option to explicitly close them?

PR sent - see #2.


System Light/Dark Theme

Please add a setting to use the system light/dark theme for the app

Will be added in upcoming releases.


⚠ Site ANTS has degraded performance

In d166e80, Site ANTS (https://ants.gouv.fr) experienced degraded performance:

HTTP code: 200
Response time: 11996 ms

Resolved: Site ANTS performance has improved in a5c6dd6.


clickhouse-obfuscator missing symlink fixed

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en
Short description (up to few sentences):
This fixes #5816

Does it help?

Please fill the description.

Reopened because of github issues


Send fabrication parameters to the backend

Need to fix the js scripts in the DatasetFabrication folder to properly send the parameters to the Flask application.

addressed in #6


plugins/nvim-colorizer: add missing options

Adds the always_update, virtualtext_inline and virtualtext_mode options to nvim-colorizer.

@mergifyio queue

Wait, I think you are referencing the wrong plugin.
We use https://github.com/norcalli/nvim-colorizer.lua which doesn't seem to have those options.

I have conducted a thorough clean up in #2616.


(0, 0) similarity

Hello! While using the method described in your API "For advanced use cases", I have encountered some examples that give the "IndexError: index 1 is out of bounds for axis 0 with size 0" error when trying to highlight, [0,0] similarities and (array([], dtype=float64), array([], dtype=float64)) slices. It seems as if they are processed incorrectly by copydetect, since there are some similar lines in them. In case of solutions which have only one line (like "print(0)" in python) adding something (like "import numpy as np") to them helps. I would like to know whether this is a bug or your tool is supposed to work this way.
>>> fp6 = copydetect.CodeFingerprint("solution 2.py", 25, 1)
>>> fp8 = copydetect.CodeFingerprint("solution 4.py", 25, 1)
>>> token_overlap, similarities, slices = copydetect.compare_files(fp6, fp8)
>>> print(similarities, slices)
(0, 0) (array([], dtype=float64), array([], dtype=float64))
>>> code1, _ = copydetect.utils.highlight_overlap(fp1.raw_code, slices[0], ">>", "<<")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/copydetect/utils.py", line 163, in highlight_overlap
    hl_percent = np.sum(slices[1] - slices[0])/len(doc)
IndexError: index 1 is out of bounds for axis 0 with size 0

solution 2.py:
a1 = []  # new list
n = int(input())  # length of list
for i in range(n):
    new_element = int(input())  # new element
    a1.append(new_element)  #

b1 = [] # new list
m = int(input())  # length of list
for i in range(m):
    new_element = int(input())  # new element
    b1.append(new_element)  #

s1 = set(b1)
ans = []
for i in range(n):
    if a1[i] in s1:
        ans.append(a1[i])

print(ans)

solution 4.py:
n = int(input())
#writing something here#writing something here#writing something here
lst = []#writing something here#writing something here#writing something here
for i in range(n):#writing something here#writing something here
    lst.append(int(input()))#writing something here
m = int(input())

lst2 = []#writing something here
for i in range(m):#writing something here
    lst2.append(int(input()))#writing something here

set_int = set(lst).intersection(set(lst2))#writing something here
res_lst = []#writing something here
for i in range(n):#writing something here#writing something here#writing something here#writing something here
    if (lst[i] in set_int):#writing something here#writing something here
        res_lst.append(lst[i])#writing something here#writing something here#writing something here

print(res_lst)#writing something here#writing something here#writing something here#writing something here

the same also happens for the following solutions:
#include<bits/stdc++.h>

using namespace std;
#define forn(i, n) for(int i = 0; i < int(n); i++)
#define f first
#define s second
#define ll long long
#define db double
#define pb push_back
typedef pair<int, int> pii;

void inppp(){
    freopen("input.txt", "r", stdin);
    freopen("output.txt", "w", stdout);
}

const int M = 1e9 + 7;
const int MAXN = 1e3 + 5;

//double ans = 0;

int main() {
	inppp();
	//setprecision(12);
	double t = 1;
	//cin >> t;
	int n;
	cin >> n;
	vector<int> arr(n);
	for(int i = 0; i < n; i++)
		cin >> arr[i];
	sort(arr.begin(), arr.end());

	int c = 1;
	for(int i = 1; i < n; i++) {
		if(arr[i] - arr[i - 1] > 1) c = 0;
	}

	cout << c << endl;

	return 0;
}

#include <iostream>
#include <algorithm>
#include <vector>
#include <map>
#include <set>
#include <iomanip>
#include <fstream>
#include <cmath>

using namespace std;

int check(ifstream &fin, int n)
{
  vector<int> vec;
  int a;

  while(fin >> a)
    vec.push_back(a);

  sort(vec.begin(), vec.end());

  for (int i = 0; i < n-1; ++i)
  {
    if (!(abs(vec[i]-vec[i + 1]) <= 1))
      return 0;
  }

  return 1;
}

int main()
{
  ifstream fin("input.txt");
  ofstream fout("output.txt");

  int a0;

  if (fin >> a0)
    fout << check(fin, a0);

  fin.close();
  fout.close();

  return 0;
}

Thanks for the report. The fact that no similarity is detected for these files is more of a limitation of the algorithm than a bug. It simply means there are no sequences of 25 tokens or more overlapping between the tokenized versions of the two files. For reference, this is what the python files look like in tokenized form:
>>> fp1 = CodeFingerprint("sol2.py", 25, 1)
>>> fp1.filtered_code
'V=[]V=int(input())forVinrange(V):V=int(input())V.V(V)V=[]V=int(input())forVinrange(V):V=int(input())V.V(V)V=set(V)V=[]forVinrange(V):ifV[V]inV:V.V(V[V])print(V)'
>>> fp2 = CodeFingerprint("sol4.py", 25, 1)
>>> fp2.filtered_code
'V=int(input())V=[]forVinrange(V):V.V(int(input()))V=int(input())V=[]forVinrange(V):V.V(int(input()))V=set(V).V(set(V))V=[]forVinrange(V):if(V[V]inV):V.V(V[V])print(V)'

You can always increase the sensitivity of the algorithm -- I found that with noise_threshold = 15 and guarantee_threshold = 15 copydetect reported a similarity of around 50% for those two files. However, using lower thresholds will also increase the false positive rate. I would recommend experimenting with the threshold a bit (unless you're running into performance issues it's best to adjust them together, i.e. noise_threshold = guarantee_threshold).
The crash here is happening because highlight_overlap assumes there is at least some similarity to highlight, which in this case there isn't. That is a bug, I should have a fix for it soon.

Thank you for the answer and explanation!


Init proyect fails in compliate version android

Description
The project fails following the instructions. In other words, the template fails for android. This generates a Java error.
Reproduction Steps and Sample Code
No example code, because is the template. Starts proyect and run
$ react-native init myProyect
$ cd myProyect
$ react-native run-android

Prints
Building and installing the app on the device (cd android && ./gradlew installDebug)...
Incremental java compilation is an incubating feature.

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':app'.
> java.lang.NullPointerException (no error message)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 24.996 secs
Could not install the app on the device, read the error above for details.
Make sure you have an Android emulator running or a device connected and have
set up your Android development environment:
https://facebook.github.io/react-native/docs/android-setup.html

Additional Information

react 16.0.0-alpha.6
react-native 0.44.0
Platform : Android
OS: MacOX Sierra
Dev tools: Android Studio

try  delete node_modules in your root directory.
npm install<EMAIL_ADDRESS>--save
 npm install<EMAIL_ADDRESS>--save
npm install

Or just remove any ^ in front of version numbers in package.json and do npm install.
Make sure you have emulator running.
You might need to run packager using npm start  and then react-native run-android or just npm start and use studio to run Android application as usual. Let us know what happens!

That is not a solution

show us your package.json contents and also tell us what versions of react and react-native are actually installed.  Remember you sometimes need to do:
npm start
then
react-native run-ios/android
npm list | grep 'react@'        // what version is really installed?
npm list | grep 'react-native@'  // what version of react native?
React Native works out of the box.

├─┬<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ ├──<EMAIL_ADDRESS>deduped

@alejonext I had the same error; have you installed the Android SDK via brew? Removing gradle via brew uninstall gradle and installing the SDK manually did the trick for me.
Be sure to set the correct environment variables afterwards and reload your shell.

Hi there! This issue is being closed because {:search=>"repo:facebook/react-native is:open is:issue updated:<2017-05-25 -label:"Good First Task" -label:"Help Wanted" ", :message=>"it has been inactive for a while"}. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!
If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.

In case someone run into this issue, just open the project in Android Studio, wait a bit for it to update something and then run "react-native run-android" again.

This issue still exist in react-native: 0.53.0

@madeeha96 feel free to open a new issue with any details specific to your problem.

My issue is resolved now by changing android SDK version
1-) change version of android SDK in build.gradle file

Add google() to repositories if it's only jcenter()
repositories {
jcenter()
google()   ----> (add this)
dependencies {
classpath 'com.android.tools.build:gradle:3.0.1'  (previously it was 2.2.3)

2-) Add following line to graddle-wrapper.properties
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https://services.gradle.org/distributions/gradle-4.1-all.zip  ( upgrade it)
distributionUrl=https://services.gradle.org/distributions/gradle-2.14.1-all.zip (previous version)
3-) Then run 'react-native-run-android'
works out for me!!!


show profile errors

Details

Proposal: https://github.com/Expensify/App/issues/5091#issuecomment-912915366
Approval: https://github.com/Expensify/App/issues/5091#issuecomment-914171930
After this PR is merged, we will be showing error messages when longer names (50+ chars) are being saved.
And profile updation will now wait for the API call to be completed to show the correct msg to user.
Fixed Issues

$ https://github.com/Expensify/App/issues/5091
Tests

Navigate to settings > Profile
Change the first or last name to something over 50 characters
Save the changes
error message be shown
Refresh the page or close the modal
Name will remain unchanged if there is an error.

QA Steps

Tested On

[x] Web
[x] Mobile Web
[ ] Desktop
[ ] iOS
[x] Android

Screenshots

Web

https://user-images.githubusercontent.com/83179295/134774806-cc94431c-b3b0-46ba-bbca-ca5efb672fa9.mp4
Mobile Web

https://user-images.githubusercontent.com/83179295/134774812-93ba8af8-820d-4721-b5f7-7e791728a581.mp4
Desktop

iOS

Android

https://user-images.githubusercontent.com/83179295/134774658-b83b9723-4ff3-4af5-b2fc-d8e9548db366.mp4

🚀 Deployed to staging by @Beamanator in version: 1.1.8-10 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Migrate article: Attach VPC to AWS Transit Gateway

Migrate the content from this article to fit the documentation portal format https://help.aiven.io/en/articles/3507710
(Assign this issue to yourself before you start, and remember to mention the issue number when you open your pull request)

From the existing article:

Note that cross-region attachments are not currently supported by TGW.

From AWS documentation:

At re:Invent 2019 we announced that AWS Transit Gateway now supports inter-Region peering. This means that all the Amazon VPCs, Site-to-Site VPN connections, and Direct Connect gateways attached to an AWS Transit Gateway hosted in one AWS Region can exchange traffic with resources deployed in other AWS Regions.

Looking to validate this and get suggestion on possible edits to the existing article from an SA colleague.

The Aiven AWS account ID is<PHONE_NUMBER>24.

Is this ID static and Ok to be on public docs?


clean-webpack-plugin 的使用方法改变了

const { CleanWebpackPlugin } = require('clean-webpack-plugin');
describe your changes...

[ ] Read and sign the CLA. PRs that haven't signed it won't be accepted.
[ ] Make sure your PR complies with the writer's guide.
[ ] Review the diff carefully as sometimes this can reveal issues.
Remove these instructions from your PR as they are for your eyes only.

已修复


docs: new image

Description
Correct few things in arch diagram
Types of changes in this PR
Changes that affect the core Terraform module or submodules

[ ] Bug fix
[ ] New feature
[ ] Dependency update

Changes that don't affect the core Terraform module or submodules

[ ] Examples or tests (addition or updates of examples or tests)
[x] Documentation update
[ ] CI-related update (pipeline, etc.)
[ ] Other

Release required?
Identify the type of release. For information about the changes in a semantic versioning release, see Release versioning.

[ ] No release
[ ] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content
If a release is required, replace this text with information that users need to know about the release. Write the release notes to help users understand the changes, and include information about how to update from the previous version.
Your notes helps the merger write the commit message for the PR that is published in the release notes for the module.

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

Merge actions for mergers

Use a relevant conventional commit message that is based on the PR contents and any release notes provided by the PR author. The commit message determines whether a new version of the module is needed, and if so, which semver increment to use (major, minor, or patch).
Merge by using "Squash and merge".

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

GitHub release
v8.1.0

Your semantic-release bot :package::rocket:

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

GitHub release
v8.1.0

Your semantic-release bot :package::rocket:


Make size of cluster configurable

Currently the cluster is fixed at 6 nodes, 3 master with each one slave. This configuration should should be dynamic and allow for change to possibly test different scenarios.

Closing this one as invalid. There is no real need or use-case to have this configurable as is. A cluster with 6 nodes and 2 standalone nodes is good enough for now.