@ngx-formly/json-schema

1. Progress of supported schema:

[x] string

[x] Length (minLength, maxLength)
[x] Regular Expressions (pattern)
[ ] Format

[x] Numeric types

[x] integer
[x] number
[x] Multiples (multipleOf)
[x] Range (minimum, exclusiveMinimum, maximum and exclusiveMaximum)

[x] minimum and maximum
[x] exclusiveMinimum and exclusiveMaximum

[x] object

[x] Properties
[x] Required Properties
[ ] Property names
[ ] Size
[x] Dependencies
[ ] Pattern Properties

[x] array

[x] Items
[x] Length
[x] Uniqueness
[ ] contains

[x] boolean
[x] null
[x] Generic keywords

[x] Annotations (title, description, default)
[x] Enumerated values
[x] Constant values

[ ] Media: string-encoding non-JSON data

[ ] contentMediaType
[ ] contentEncoding

[ ] Combining schemas

[x] allOf
[x] anyOf
[x] oneOf
[ ] not

[ ] Applying subschemas conditionally (if, then and else)
[x] Structuring a complex schema

[x] $ref
[ ] $id

[ ] extra options

[x] widget
[x] map
[ ] uiSchema
[ ] convert formly schema to json-schema

2. add @ngx-formly/json-schema
3.Docs

[ ] add guide section
[ ] improve demo examples
[ ] options

[ ] widget
[ ] map
[ ] uiSchema

@aitboudad @kenisteward I've followed your issue #1348 and I'd like to start developing on some of those things (as mentioned in my original issue description), specifically I'd need

dynamic select boxes/autocompletes (i.e. where the data is fetched on the fly by giving it a source URL to the API)
datepickers

And for those, the main issues I'm currently encountering is

where to define the "widget" to use, i.e. <select> or some custom autocomplete, basically what would then translate to some formly type.
where to put custom attributes, like the source (or how you'd call it) property that specifies the URL where to fetch the entries for the select box

I started giving a look to:

https://mozilla-services.github.io/react-jsonschema-form/
http://guillotina.io/ngx-schema-form/dist/ngx-schema-form/json

They often use a widget property, which seems to be custom though, as I couldn't find it in the spec. We had a similar strategy, like for mapping an autocomplete of people like
{
  "title": "test",
  "type": "object",
  "properties": {
    "personId": {
      "type": "integer",
      "title": "Owner",
      "widget": {
        "type": "autocomplete",
        "source": "/api/options/people.json"
      }
    }
  }
}

Validating it against this validator https://www.jsonschemavalidator.net/ seems to work and be valid.
What's your opinion on this?

The main issue here is there is no concept of a "layout.json" yet.  This
I'd something I've been looking into adding for the json-schema generations
for the past month. I've gone through 1 or 2 partial iterations and am
formulating a plan for it. I can post my findings here or start a new issue
for it
I've also taken some inspiration from
Angular6-json-schema-form.
The biggest issue with that project is it is not maintained.
Once we have the concept of the layout.json in formly ( which awkwardly
enough can technically be a formly config ) we can use that while parsing
the fields to define formgroup layouts and special options like the one you
stated.
On Thu, Mar 7, 2019, 8:23 AM Juri Strumpflohner<EMAIL_ADDRESS>wrote:

@aitboudad https://github.com/aitboudad @kenisteward
https://github.com/kenisteward I've followed your issue #1348
https://github.com/ngx-formly/ngx-formly/issues/1348 and I'd like to
start developing on some of those things (as mentioned in my original issue
description), specifically I'd need

dynamic select boxes/autocompletes (i.e. where the data is fetched
on the fly by giving it a source URL to the API)
datepickers

And for those, the main issues I'm currently encountering is

where to define the "widget" to use, i.e.  or some custom
autocomplete, basically what would then translate to some formly type.
where to put custom attributes, like the source (or how you'd call
it) property that specifies the URL where to fetch the entries for the
select box

I started giving a look to:

https://mozilla-services.github.io/react-jsonschema-form/
http://guillotina.io/ngx-schema-form/dist/ngx-schema-form/json

They often use a widget property, which seems to be custom though, as I
couldn't find it in the spec. We had a similar strategy, like for mapping
an autocomplete of people like
{
"title": "test",
"type": "object",
"properties": {
"personId": {
"type": "integer",
"title": "Owner",
"widget": {
"type": "autocomplete",
"source": "/api/options/people.json"
}
}
}
}
Validating it against this validator https://www.jsonschemavalidator.net/
seems to work and be valid.
What's your opinion on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ngx-formly/ngx-formly/issues/1459#issuecomment-470544383,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMPLtWJ7GJuiHdDPBeTnQqLAUKm_8NEEks5vUSDjgaJpZM4bir7f
.

Also one of the key things I wanted to do was to make sure we started with
the separate layout.json and allowed it to be combined later.
Also one of the issues with the form given now is that you can't make
arbitrary wrapper elements in that form. You can only define fields for
elements.  Defining arbitrary wrapper elements for grouping of elements is
basically a must have.
On Thu, Mar 7, 2019, 8:30 AM Kenneth Steward<EMAIL_ADDRESS>wrote:

The main issue here is there is no concept of a "layout.json" yet.  This
I'd something I've been looking into adding for the json-schema generations
for the past month. I've gone through 1 or 2 partial iterations and am
formulating a plan for it. I can post my findings here or start a new issue
for it
I've also taken some inspiration from
Angular6-json-schema-form.
The biggest issue with that project is it is not maintained.
Once we have the concept of the layout.json in formly ( which awkwardly
enough can technically be a formly config ) we can use that while parsing
the fields to define formgroup layouts and special options like the one you
stated.
On Thu, Mar 7, 2019, 8:23 AM Juri Strumpflohner<EMAIL_ADDRESS>wrote:

@aitboudad https://github.com/aitboudad @kenisteward
https://github.com/kenisteward I've followed your issue #1348
https://github.com/ngx-formly/ngx-formly/issues/1348 and I'd like to
start developing on some of those things (as mentioned in my original issue
description), specifically I'd need

dynamic select boxes/autocompletes (i.e. where the data is fetched
on the fly by giving it a source URL to the API)
datepickers

And for those, the main issues I'm currently encountering is

where to define the "widget" to use, i.e.  or some custom
autocomplete, basically what would then translate to some formly type.
where to put custom attributes, like the source (or how you'd call
it) property that specifies the URL where to fetch the entries for the
select box

I started giving a look to:

https://mozilla-services.github.io/react-jsonschema-form/
http://guillotina.io/ngx-schema-form/dist/ngx-schema-form/json

They often use a widget property, which seems to be custom though, as I
couldn't find it in the spec. We had a similar strategy, like for mapping
an autocomplete of people like
{
"title": "test",
"type": "object",
"properties": {
"personId": {
"type": "integer",
"title": "Owner",
"widget": {
"type": "autocomplete",
"source": "/api/options/people.json"
}
}
}
}
Validating it against this validator https://www.jsonschemavalidator.net/
seems to work and be valid.
What's your opinion on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ngx-formly/ngx-formly/issues/1459#issuecomment-470544383,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMPLtWJ7GJuiHdDPBeTnQqLAUKm_8NEEks5vUSDjgaJpZM4bir7f
.

If you're ok with that, I'll post ideas on how to evolve the current implementation here to discuss with you

that's a good news, my thought about this part can be found here https://github.com/ngx-formly/ngx-formly/issues/1056#issuecomment-410301293

what's currently possible

the majority of use-cases, except two parts which are mentioned in the V6 roadmap:

custom validation
allow passing custom UISchema

react-jsonschema-form is a good lib to follow, once we've done with that part, the next step is to wrap the FormlyJsonschema service within a component.

I can post my findings here or start a new issue
for it

If ur ok, let's post here and use this as the main discussion issue around evolving the json-schema part of formly (if also @aitboudad agrees).

I've also taken some inspiration from
Angular6-json-schema-form.
The biggest issue with that project is it is not maintained.

Ya, I've quickly seen that one too. Well, if it is not maintained, we might take inspiration from their ideas and port it over.

Also one of the key things I wanted to do was to make sure we started with
the separate layout.json and allowed it to be combined later.

Sounds good for me, would love to get some more insight in your ideas.

Also one of the issues with the form given now is that you can't make
arbitrary wrapper elements in that form. You can only define fields for
elements.  Defining arbitrary wrapper elements for grouping of elements is
basically a must have.

💯 agree.

the majority of use-cases

@aitboudad how would you implement the "widget" scenario though? Like distinguishing between an autocomplete, date picker,...?

how would you implement the "widget" scenario though? Like distinguishing between an autocomplete, date picker,...?

If I'm not mistaken that would be solved by UISchema which can be passed as a second argument to
FormlyJsonschema::toFieldConfig but I think your proposal is better if it's a valid json-schema.

If I'm not mistaken that would be solved by UISchema

Yep I've seen the usage of UISchema in the react form example. The UISchema allows for sure to have more complex configurations, having a widget directly attached, makes it a bit easier to handle everything though, from the server side that generates the JSONSchema as well as the client-side. I've seen that being used in ngx-schema-form.
From a first check it seems to be "valid", in the sense it's being ignored as far as I could tell. Pasted it into the https://www.jsonschemavalidator.net/, although I'm not 100% sure that tool does a proper validation. I'll check.
Do you have any prefs on how that widget should be structured internally?

Do you have any prefs on how that widget should be structured internally?

The more we're in line with the existing solution the more is better but always keep it simple,
if possible widget should be FormyFieldConfig which will be merged with the converted field:
mySchema = {
  "properties": {
    "pageContent": {
      "type": "string",
      "description": "Page content",
      "widget": {
        "type": "select",
        "templateOptions": {
          ...
        }
      }
    }
  }
}

well if that is allowed, it can be implemented easily by merging the converted field with the widget

well if that is allowed, it can be implemented easily by merging the converted field with the widget

Agree 👍 . @kenisteward any insights from your part? Otherwise I'll provide a PR with a 1st implementation of the widget prop.
the widget.type would then overwrite the formlyFieldConfig.type in case it is specified. Thus if I have a formly type registered - say ng-select, then I could specify ng-select on that widget.type & it would automatically instantiate that formly field.

@juristr
https://www.jsonschemavalidator.net/
is a reference to using schema 7 spec.  In that, you are allowed to have any additional properties based on the base schema spec for a jsonSchema.  That is why it doesn't fail.

Via remote url that returns [{ label: '...', value: ...}, ...]

The proper utilization for what should be returned in a schema is defined here:
https://github.com/json-schema-org/json-schema-spec/issues/57#issuecomment-247861695
This basically states that a value will be oneOf these schemas which are represented by const/title combination.  Other libraries implement this as should we.  This allows for your schema to define what your select list options should be.
https://hamidihamza.com/Angular6-json-schema-form/?set=ng-jsf&example=ng-jsf-select-list-examples&framework=material-design&language=en
is an example of the idea in angular6-json-schema-form
The reason I bring this up is what you could do is for the field add a $ref link to get a "schema" that is dynamically generated based on the values you want it in.  That way when the fields are being built from the schema we can have them there.  If your use case is for live updates as they type though then we'd just have to implement it in the field like you have it.

well if that is allowed, it can be implemented easily by merging the converted field with the widget

Agree 👍 . @kenisteward any insights from your part? Otherwise I'll provide a PR with a 1st implementation of the widget prop.

I'm not sure currently how we can use this setup to allow arbitrary wrappers for fields.
Example: https://hamidihamza.com/Angular6-json-schema-form/?set=ng-jsf&example=ng-jsf-flex-layout&framework=material-design&language=en
Adding the widget option would 100 percent allow us to have layout information for specific fields but I don't think it allows us to say:
with this example schema:
 {    "$schema": "http://json-schema.org/draft-07/schema#",     "type": "object",     "properties": {       "first_name": { "type": "string" },       "last_name": { "type": "string" },       "address": {         "type": "object",         "properties": {           "street_1": { "type": "string" },           "street_2": { "type": "string" },           "city": { "type": "string" },           "state": {             "type": "string",             "enum": [ "AL", "AK", "AS", "AZ", "AR", "CA", "CO", "CT", "DE",                 "DC", "FM", "FL", "GA", "GU", "HI", "ID", "IL", "IN", "IA",                 "KS", "KY", "LA", "ME", "MH", "MD", "MA", "MI", "MN", "MS",                 "MO", "MT", "NE", "NV", "NH", "NJ", "NM", "NY", "NC", "ND",                 "MP", "OH", "OK", "OR", "PW", "PA", "PR", "RI", "SC", "SD",                 "TN", "TX", "UT", "VT", "VI", "VA", "WA", "WV", "WI", "WY" ]           },           "zip_code": { "type": "string" }         }       }     },     "required": [ "last_name" ]   }
Say:
I want to put first_name and last_name with address.street_1 on the same row
then put the rest of the fields within address inside a wrapper container element.
I think with formly, you normally have to create those "wrapper container" formgroups by hand and put what fields you want to in them (I did this with the first iteration of the form maker I'm trying internally).
Sorry for the wall of text :(

I want to put first_name and last_name with address.street_1 on the same row
then put the rest of the fields within address inside a wrapper container element.

well it can be done :) here is an early implementation: https://stackblitz.com/edit/angular-rbv4qw

in the end, I think we should provide both ways because for a large form it's better to separate your UI config from your schema.

@aitboudad THIS IS EVIL MAGIC SORCERY AND I LOVE IT!
I'm all for this type of layout.json.
If I understand this correct, we could also set a formly wrapper component set and have it generically handle making "sections".  I see you just used a class here to get the point across and it looks great!
The only thing that was throwing me off is that in the schema that was input into the toFormlyConfig() function, it had the address.street1 in a different place than it should show in the original schema when validated but it properly was in the correct place in the form data.   That may be because they are combined and so in the combined state it represents layout first and then the underlying data with the key names.  the most important thing is to make sure that when the data is sent across it is in the proper format of the original "data schema" which I think this covers anyway.

in the end, I think we should provide both ways because for a large form it's better to separate your UI config from your schema.

100% agree.  I'm personally working on multiple large form sets and have had to split them down and found it easier to work on with the two separate.

Awesome guys 🎉. So I guess we can agree on the widget object being used. Let's start incrementally. Most probably on Monday I'll start with a first PR for implementing a select that can be bound to an API endpoint for fetching the data. I'll post my JSONSchema definition here before starting the implementation.
Thx for now :)

https://json-schema.org/understanding-json-schema/structuring.html
https://json-schema.org/latest/json-schema-core.html#rfc.section.8.3
This is something else I thought we want to make sure we support. Right now, the implementation knows nothing of $ref ( local or external reference )  the spec right now states that if $ref is found all of the validation keys ( type, minlength, maximum etc) should be pulled from ref and ignored in the schema referencing it. Annotations like $comment , title, description etc don't have to be.  Different forms validators handle it differently.
Also in spec 8 (coming soon) there will be a definition for saying which pieces in a ref you want to take ( I think ).

Alright, so I started implementing the select with dynamic data. @aitboudad I like the "MAGIC SORCERY" (as @kenisteward called it 😄 ) from your example.
I'd add the..
if (schema['widget']) {
    return reverseDeepMerge(field, schema['widget']);
}

...part into the current FormlyJsonschema. The only thing I'd change is to maybe move it into a sub-property of the widget. like
{
   ...
   widget: {
      formlyConfig: { ... }
   }
}

The main reason is to allow having other configs in the widget part as well, which Formly shouldn't just merge onto the config by default. Just like in my case with the select, I'm having
{
   ...
   widget: {
      source: '/api/options/people.json',
      formlyConfig: {
        type: 'select'
     }
   }
}

That way, Formly automatically merges the select configuration, and after that I check for the source property and load the according data onto that templateOptions.options in whatever way I like.
Another point: What do you think about changing the current signature of the toFieldConfig in a way to add an optional mapFn?
toFieldConfig(jsonSchema: JSONSchema7, mapFn?: mappingCallbackFn): FormlyFieldConfig {
  ...
}

..where the mapFn is defined as
export type mappingCallbackFn = (mappedField: FormlyFieldConfig, mapSource: JSONSchema7) => FormlyFieldConfig;

That allows to hook that in and get called back by Formly for each field config. Basically the FormlyJsonschema would do its mapping first and then call the mapFn (if defined), passing the mapped FormlyFieldConfig + the original JSONSchema part that was used to create it.
Any thoughts on this?

Alright, so I started implementing the select with dynamic data. @aitboudad I like the "MAGIC SORCERY" (as @kenisteward called it smile ) from your example.

me too, that comment is much magic too :smile:

The only thing I'd change is to maybe move it into a sub-property of the widget. like ...

it makes sense

Another point: What do you think about changing the current signature of the toFieldConfig in a way to add an optional mapFn?

I'm ok with that but I would prefer the following signature instead, to allow adding more options if needed.
toFieldConfig(jsonSchema: JSONSchema7, options: { mapFn?: mappingCallbackFn}): FormlyFieldConfig {
}

I'm ok with that but I would prefer the following signature instead, to allow adding more options if needed.

Oh yes absolutely 👍
I'll submit a PR once I have it

What about allowing a value to be validated against multiple criteria at the same time.
https://json-schema.org/understanding-json-schema/reference/combining.html
{
  "anyOf": [
    { "type": "string", "maxLength": 5 },
    { "type": "number", "minimum": 0 }
  ]
}

The keywords used to combine schemas are:

allOf: Must be valid against all of the subschemas
anyOf: Must be valid against any of the subschemas
oneOf: Must be valid against exactly one of the subschemas
All of these keywords must be set to an array, where each item is a schema.

In addition, there is:

not: Must not be valid against the given schema

Or
Is this element already implemented? I couldn't find it.

@Adam-Michalski not yet, based on the provided description it shouldn't be hard to implement using the map callback until formly support that part.
I'll try to provide an example when time allows.

Updated the summary of this issue :) to track all remaining features.
The $ref and dependencies are implemented a PR is scheduled next week :+1:
Once done with the remaining part, in V6.1 the FormlyJsonschema service will be wrapped within a component and moved into a sub-package @ngx-formly/json-schema:
<formly-json-schema [schema]="schema" [uiSchema]="uiSchema" [options]="options">
<formly-json-schema>

@aitboudad were you able to implement dependencies with  $id and async http calls in mind. I've been trying to figure out a non obtrusive way to do it.  I was only able to figure out non url based ones with the current api because asyc // await kinda messed things up.
My original idea was to follow suit with ajv and make a separate "compileAsync" function but that seemed not as good

@kenisteward I'm doing that right now by having a JSON schema like
anotherId: {
      type: 'integer',
      title: 'Some Select',
      widget: {
        source: '/api/options/people.json',
        formlyConfig: {
          type: 'select'
        }
      },
      propertyOrder: 2
    },

..and then by using the formlyJsonSchema.toFieldconfig(jsonSchema, ..) and the according map that can be passed to it to wrap all the configs having a widget.source defined in an observable HTTP call. Something like
this.formlyJsonSchema.toFieldConfig(jsonSchema, {
    map: (field: FormlyFieldConfig, source: JSONSchema7) => {
        // TODO: manually map the http observable here to the field
    }
})

That works pretty good

@juristr
Could you give a full example of your json?
I wouldn't just be filling in a select or a particular field. This would be more for resolving external schemas by the Json schema spec
E.g. https://json-schema.org/understanding-json-schema/structuring.html
Scroll down to the example with using $id with $ref
Also the actual specification here is a really good example.
https://json-schema.org/latest/json-schema-core.html#rfc.section.8.2.4

@kenisteward Remote schemas not supported yet, the solution is to add an options for that:
toFieldConfig(schema, { resolveSchema: (url) => this.http.get(url) });

and in that case toFieldConfig will be async

This is actually what I had in mind but I wasn't sure if you also were okay with making the whole function asynchronous

@aitboudad did you end up making the PR?  I was going to add the async to what you had and I didn't want to end up causing merge issues.

@kenisteward I've pushed my initial work (https://github.com/aitboudad/ngx-formly/tree/json-schema-deps) but I'd prefer you to wait until I'm getting back to work next week.

Could it be published as some kind of alpha version? I would really help me out.

@olaf89 not ready for production, but if you want  to try it
just copy the FormlyJsonschema service and include it on your project.

Thanks, i am testing it and it looks like it works well. I need to implement allOf, would you like me to submit pr with it when im done?

This is something else I thought we want to make sure we support. Right now, the implementation knows nothing of $ref ( local or external reference ) the spec right now states that if $ref is found all of the validation keys ( type, minlength, maximum etc) should be pulled from ref and ignored in the schema referencing it. Annotations like $comment , title, description etc don't have to be. Different forms validators handle it differently.

@kenisteward can you point me to the doc where was it mentioned?

@aitboudad
https://json-schema.org/latest/json-schema-core.html#rfc.section.8.3
Here's the main spec for $ref. Above it talks about how $id should work
with $ref
On Tue, Jul 9, 2019, 6:05 AM Abdellatif Ait boudad<EMAIL_ADDRESS>wrote:

This is something else I thought we want to make sure we support. Right
now, the implementation knows nothing of $ref ( local or external reference
) the spec right now states that if $ref is found all of the validation
keys ( type, minlength, maximum etc) should be pulled from ref and ignored
in the schema referencing it. Annotations like $comment , title,
description etc don't have to be. Different forms validators handle it
differently.
@kenisteward https://github.com/kenisteward can you point me to the doc
where was it mentioned?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ngx-formly/ngx-formly/issues/1459?email_source=notifications&email_token=ADB4XNOC6EG5TKYA4BIFJ33P6RWIXA5CNFSM4G4KX3P2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZP5RFI#issuecomment-509597845,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADB4XNMPEYIVRJ4MMTXBP6TP6RWIXANCNFSM4G4KX3PQ
.

if $ref is found all of the validation keys ( type, minlength, maximum etc) should be pulled from ref and ignored in the schema referencing it. Annotations like $comment , title, description etc don't have to be.

if title is defined with $refs, should we take account of it or ignore it, I couldn't find any information about it from the spec.
{
  $ref: "#/definitions/address",
  title: "billing address"
};

@aitboudad
It is up to use to choose.  I preferably think using the topmost level annotation is best.  That way it allows us to override titles if we are sharing schemas.

From the spec An object schema with a "$ref" property MUST be interpreted as a "$ref" reference. The value of the "$ref" property MUST be a URI Reference. Resolved against the current URI base, it identifies the URI of a schema to use. All other properties in a "$ref" object MUST be ignored.

I realize that but 1. That's changing in draft 8 and 2 that is not a great
experience to program under.
The annotations are actually meant to help for UI generation needs. It is
important for validators to overwrite the referenced validation terms but
not the annotations
On Tue, Jul 9, 2019, 12:41 PM Olaf Kasper<EMAIL_ADDRESS>wrote:

From the spec An object schema with a "$ref" property MUST be interpreted
as a "$ref" reference. The value of the "$ref" property MUST be a URI
Reference. Resolved against the current URI base, it identifies the URI of
a schema to use. All other properties in a "$ref" object MUST be
ignored.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ngx-formly/ngx-formly/issues/1459?email_source=notifications&email_token=ADB4XNIJSI4HRJVCJCBXASLP6TES5A5CNFSM4G4KX3P2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZQ7WSI#issuecomment-509737801,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADB4XNKO4SCJSN6L36MFZFDP6TES5ANCNFSM4G4KX3PQ
.

seems clear now, added the annotations (title, description and default) support.
please check my PR #1658 and let me know if I'm not missing something.
Thanks!

Thanks, i am testing it and it looks like it works well. I need to implement allOf, would you like me to submit pr with it when im done?

@olaf89 PR welcomed :)

@aitboudad I want to try to add support for If Then Else this weekend.
http://json-schema.org/latest/json-schema-validation.html#rfc.section.6.6
The idea is that the if schema decides whether you will validate with the then or else schema.
Valid to if = use then schema for a validation result (if present)
invalid to if = then else schema for validation result (if present)
otherwise we completely ignore the keywords.
I saw how you implemented dependencies and I wanted to follow along with that but I realized dependencies works because if it is defined then you will be using it no matter what
(e.g. we can eagerly add the config to validate on the deps added because they are setting up basically required relationships.)
in the case of if then else, we don't want to apply one or the other based on the data there.
Is there a way to conditionally use formly configs?  I think that may more directly correlate to the If/thenelse/use case.

Is there a way to conditionally use formly configs?

hideExpression allow applying formly configs conditionally, https://ngx-formly.github.io/ngx-formly/examples/field-options/hide-fields

@aitboudad
I think I have an idea on how to properly do it but I'm not sure if I can find a way to set formstate from instead a field.
The idea would be something like this:
    if (schema.if) {
      const uniqueId = generateUniqueId();
      const ifConfig = this._toFieldConfig(<JSONSchema7> schema.if, options);
       // manipulate the ifConfig to be able to change formstate to have true or false when
       // the if config is valid or invalid.  This should not change the model

      // schema.then
      const thenConfig = this._toFieldConfig(<JSONSchema7> schema.then, options);
      thenConfig.hideExpression = (m, f) => f[`${f.key}-${uniqueId}-if`];

      // schema.else
      const elseConfig = this._toFieldConfig(<JSONSchema7> schema.else, options);
      elseConfig.hideExpression = (m, f) => !f[`${f.key}-${uniqueId}-if`];

      // add if/else/then configs to field
    }

I"m just not sure how to set the formState for that uniqueId if.  Would the be a better way of doing this as well?

@kenisteward instead rely on formControl validity:
thenConfig.hideExpression = (m, f) => !f.formControl.valid;

@aitboudad okay I'll try that.  I didn't think that was even possible for me to use!

v5.3 is released which includes the implemented json-schema features :tada:!

I'm working now on the following keywords (anyOf, oneOf and uniqueItems) which we be included in v5.5 the latest minor version of V5.
The rest of the specs will depend on the most requested ones but PR welcomed anyway!
After v5.5 release, we'll focus on the next major version v6 😍(better Doc, Api and more UIs).

A new version of the JSON Schema specification has been released:
https://json-schema.org/draft/2019-09/release-notes.html

here we go, the v5.5 is released with the following enhancements (you may check our demo example ):

validators: uniqueItems and const.
added alternative ways for custom labels to enum
multiselect type
partial support of anyOf/oneOf

@darrenmothersele thanks for the info, we'll try to bring the new updates in v6.
Happy coding 🎉🎉🎉!

@aitboudad @juristr
I’d like to use ngx-fornly to generate forms based on json-schemas. oneOf/anyOf constructions support is critical for me. I’ve considered the implementation of this functionality in<EMAIL_ADDRESS>and found out that, in fact, only oneOf logic works correctly. To support anyOf, I’ve made certain changes, which allow to display the dropdown control with multiple selection. It allows to display form controls of several anyOf array items simultaneously.
I’d like to use an original ngx-formly instead of the fork on my project. I’d appreciate if you share your thoughts regarding the changes made by me (https://github.com/ngx-formly/ngx-formly/pull/1862). I’m open for a conversation regarding the changes.

Note:
in v5.5.3 we adopted @logvinoleg89 proposal, anyOf displays the dropdown control with multiple selections.

@aitboudad how hard would it be to manipulate this to instead validate based on the rules and not have to have the user select which ones they want.
I ask because the use case would be as a developer creating the form that fits the schema and as a user just filling out a form that fits it so the user doesn't have to think about which structure it is.

@kenisteward  in my opinion, the json-schema implementation in formly may be considered as a rule rather than validation (which would fit 90% of the use cases) that why we didn't put a lot of effort in validation yet.

how hard would it be to manipulate this to instead validate based on the rules and not have to have the user select which ones they want.

that depends on the use-cases, but for more advanced scenarios mixing the formly JSON is required but we're trying to make it much easy as it can be.

I love to see the progress of json-schema in formley.
What do you guys think about remote refs?
Maybe you could let the user send in an async fn that the user are responsible for. It feel like it would this solution is advantageous instead of forcing a behaviour.
Is remote refs in the plan/making ?

Is remote refs in the plan/making ?

yep, in the plan :). It should be added through the options, something like:
options = {
  refResolver: url => this.httpClient.get(url),
}

As a heads up, I was trying to get this done but was having trouble
figuring out the proper way to implement $id with it.
On Mon, Nov 4, 2019, 7:28 AM Abdellatif Ait boudad<EMAIL_ADDRESS>wrote:

Is remote refs in the plan/making ?
yep, in the plan :). It should be added through the options, something
like:
options = {
refResolver: url => this.httpClient.get(url),
}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ngx-formly/ngx-formly/issues/1459?email_source=notifications&email_token=ADB4XNIWQEIIMKHMXEFCBQLQSAPRTA5CNFSM4G4KX3P2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC7HMVQ#issuecomment-549353046,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADB4XNOLCX5WT6FG6ZYEBMDQSAPRTANCNFSM4G4KX3PQ
.

@kenisteward in my opinion, the json-schema implementation in formly may be considered as a rule rather than validation (which would fit 90% of the use cases) that why we didn't put a lot of effort in validation yet.

how hard would it be to manipulate this to instead validate based on the rules and not have to have the user select which ones they want.

that depends on the use-cases, but for more advanced scenarios mixing the formly JSON is required but we're trying to make it much easy as it can be.

I want to confirm that I meant the implementation of anyOf / allOf to where the user doesn't have to pre select want they want to pick (current implementation assumes the user wants to select a type to fill out) and instead the fields are all given in the formly config and if the anyOf / allOf matches everything is green and okay.

@kenisteward I looked at this a while ago and it's quite confusing. I think the base thought is that all schemas should be hosted in the same location but its optional and might be on disk as well.

As a heads up, I was trying to get this done but was having trouble figuring out the proper way to implement $id with it.

If i know this correctly the default behavior as JSON-schema is:

$id is the base URL for relative $ref (even though the base file have been loaded from disk)
if $ref  is a absolute URL it should be used
{ "$ref": "person.json" } would be ($id base URL)/person.json
{ "$ref": "#person" } would just point to the definition in the same file looking for an entity with "$id" : "person"
#/definitions/person - Json Pointer
{ "$ref": "person.json#gender" } would be  ($id base)/person.json/#gender

This would be default behavior if the option is not set like @aitboudad  mentioned.
options = {
  refResolver: url => this.httpClient.get(url),
}

I want to confirm that I meant the implementation of anyOf / allOf to where the user doesn't have to pre select want they want to pick

@kenisteward not too hard to implement, I'll provide you an example if necessary.

I have worked with angular and react json schema forms for awhile. I like this package, but I really need the UI Schema support. Is there already a plan together for that? I would like to help if I can.
My json schema is from a remote ref, but it is used for a lot more than form display and I can't really tweak it just for the form - so I need to be able to have a layout defined which extends the schema, so that I can better control arrangement of the widgets.

@scottux UI Schema support will be part of 6.x version but not anytime soon, I'd suggest wrapping formly-form component in a custom one where you can add such feature for your project with the help of map fn https://github.com/ngx-formly/ngx-formly/issues/1982#issuecomment-566048527

@aitboudad that may get me through a few hurdles, but I would prefer to work on making it correct versus hacking it. If you have some kind of skeleton of an idea, I can take that and what I know from being part of https://github.com/orgs/json-schema-form to make a working Pull Request for this package.

@scottux the proper implementation would take some time TBH, I've started working on some changes (didn't have the time yet make a PR) that will allow using  json-schema without FormlyJsonschema service:
<formly-form [schema]="schema" ...></formly-form>

once done we can start on uiSchema.

@aitboudad any suggestions on how Format for strings should be implemented?  extension? parser?

@kenisteward right now the best approach is to use ngx-mask as a custom field type

@aitboudad ahh.  I wanted to add it to toFormlyConfig to have it be a solution for everyone instead of relying on my custom type.

@kenisteward once https://github.com/ngx-formly/ngx-formly/issues/180 resolved we can have a Formly solution :)

Would this issue be related to the error below?
zone-evergreen.js:171 Uncaught Error: [Formly Error] There is no type by the name of "object"

@classifieds-dev you may need to register json-schema types as shown in our demo example json-schema/app.module.ts

Ah… thanks. That looks like the missing piece.

It doesn't look there is a release of this module yet. So it looks like I need to create my own module for now and copy over whatever I need and register it in the root right?

@classifieds-dev yep, but the plan is to provide those types out of the box!

@classifieds-dev yep, but the plan is to provide those types out of the box!

This sounds awesome, I'm happy to take a shot at implementing that.
Does that mean we need to implement those json-schema related types for each of the UI libs we support?

@beeman Well we can start with the basic types already my main idea is to use the existing UI.
Example:
FormlyModule.forChild({
  types: [
    { name: 'checkbox', component: FormlyFieldCheckbox },
+   { name: 'boolean', extends: 'checkbox' },
  ],
}),

Note: use master branch.

@aitboudad that looks great!
I've started with the checkbox in this PR: https://github.com/ngx-formly/ngx-formly/pull/2232
I'd love to get some feedback. If this is the way to go, I'll create a similar commit for each of the basic types.

I think this is an amazing project. However, I've spent to much time working my way around bugs to have it be a feasible production solution.

This project is kind of pathetic. I mean… you are still talking about how to sypport json after over a year. I mean; what is happening.

@classifieds-dev  Well, that's up to you :), the essential json-schema features are supported so the remaining parts are not blocking at all, keep in mind that's a free product so the timeline may not be respected at all.

Looking to use json schema format to use a date picker.
Anything I can do to help progress efforts toward the ability to use Date-picker from a json schema
type: string
formate: date-time
?

So from the example that I found in the docs (https://stackblitz.com/angular/qkjrkdnqymvb?file=src%2Fapp%2Fobject.type.ts) I get the feeling that there is still a lot of setup and stuff to be done before being able to use formly 'out of the box' with JSON schema. Is it planned to include all these setup components etc in the core library so we don't have to do this ourselves?
For now it's just sad to see that there is so much setup code required.

What exactly do you mean by setup code?
It doesn't seem to need any more than a regular setup for firmly would need.
On Mon, Oct 5, 2020, 10:44 AM Jelle den Burger<EMAIL_ADDRESS>wrote:

So from the example that I found in the docs (
https://stackblitz.com/angular/qkjrkdnqymvb?file=src%2Fapp%2Fobject.type.ts)
I get the feeling that there is still a lot of setup and stuff to be done
before being able to use formly 'out of the box' with JSON schema. Is it
planned to include all these setup components etc in the core library so we
don't have to do this ourselves?
For now it's just sad to see that there is so much setup code required.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ngx-formly/ngx-formly/issues/1459#issuecomment-703716729,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADB4XNM7LZIQD6XS6NORIGTSJHSWJANCNFSM4G4KX3PQ
.

Hi, first of all, thank you for this awesome package! Not to sound rude but is there any eta on the resolving remote json-schema refs feature? I'll be waiting patiently :)

Hi, first of all, thank you for this awesome package! Not to sound rude but is there any eta on the resolving remote json-schema refs feature? I'll be waiting patiently :)

Hi, first of all, thank you for this awesome package! Not to sound rude but is there any eta on the resolving remote json-schema refs feature? I'll be waiting patiently :)

I had come up with a quick and dirty localized solution that I didn't want to share here yet.  Now that' we are officially in production I'll see about adding it.
@aitboudad I may need some guidance on how you want to make use of async/await for remote references.  If we leave it in the service it's fine because we can just convert that one function (from the json schema service) but if we move processing to the component it makes for uglier solutions.

Hi, first of all, thank you for this awesome package! Not to sound rude but is there any eta on the resolving remote json-schema refs feature? I'll be waiting patiently :)

I had come up with a quick and dirty localized solution that I didn't want to share here yet.  Now that' we are officially in production I'll see about adding it.
@aitboudad I may need some guidance on how you want to make use of async/await for remote references.  If we leave it in the service it's fine because we can just convert that one function (from the json schema service) but if we move processing to the component it makes for uglier solutions.

@kenisteward just go with the service solution

@kenisteward just go with the service solution

json-schema will be marked as stable in V6, the current implementation cover 90% of use-cases mores improvements in V6 series I guess :).
I'm going to close this issue and other features should be opened in a serapate issue instead.
To get the new updates make sure to subscribe to our releases.

Happy coding!

How to have a custom validator in JSON SCHEMA

Dependency custom validator

@dhairyattpl see https://github.com/ngx-formly/ngx-formly/issues/1982#issuecomment-566048527

@aitboudad @juristr
I intend to leverage the capabilities of ngx-formly extensively for my upcoming project. I have successfully implemented the solution using this technology for one of my clients, and it performed exceptionally well. Drawing upon my positive experience, I aim to take a step further and develop a product for my company.
I am reaching out to express my interest in utilizing json-schema as a fundamental format for defining my data structure, which I believe is a suitable choice as it is on track to becoming an official standard and has already been adopted by major corporations.
Although the library has fulfilled most of the standard's requirements, I have observed that there has been no progress on the related ticket for some time. Furthermore, after thoroughly reviewing all comments associated with this ticket, I am confident that your impressive service can enable us to implement the full standard.
In order to proceed, it would be immensely helpful to have detailed documentation that covers all aspects discussed in the ticket. Specifically, the mapping function, which facilitates custom manipulations of data, would be especially useful.

In order to proceed, it would be immensely helpful to have detailed documentation that covers all aspects discussed in the ticket. Specifically, the mapping function, which facilitates custom manipulations of data, would be especially useful.

@HaidarZ Thanks for you feedback, we're aware of that, the progress is a little slow but its better than nothing. Also we would appreciated any help toward improving the doc and PR welcomed!

My project needs support for contentMediaType = text/html in json schema draft-7. My expectation is that  ngx-formly will add an inline validation for string field with "contentMediaType": "text/html" if the string field is not valid HTML.
I understand that this capability is yet to be implemented. Is this the right issue for this request or should I open a new issue?


View key clean-up

There are some problems with the current view key notation that need to be cleaned up.
method colon-delimiting
The method-part of the view key needs to be colon-delimit-able so that it it can describe the effect of different methods acting on x and y. Where only 1 method is named and both x and y are present, the same method should be assumed to be working on both.
The general rule should be that method_a:method_b|x:y means the intersection of method_a(x) by method_b(y), a more concrete example being frequency:mean|x:y means the intersection of frequency(x) by mean(y).
By extension, though, this renders what is currently frequency|x:y incorrect as the key for a column base row because this should mean the intersection of frequency(x) by frequency(y), or in plain speak where the row and column bases intersect (e.g. the number of cases in either x or y).
As a consequence, the correct key for a column base row should be simply frequency|x and for a row base column frequency|y. Incidentally this is perfectly in keeping with the fundamental meaning of frequency| as basic counts, since the mention of either x or y is an implied collapse of all their values, respectively.
More examples (assuming x and y each have 3 possible values):
x|frequency||||counts
x|frequency||y||c%
x|frequency||x||r%
x|frequency|x|||cbase                      # same as x|frequency|x[(1,2,3)]|||net1-3
x|frequency|y|||rbase                      # same as x|frequency|y[(1,2,3)]|||net1-3
x|frequency|x[(1,2)]|||xnet1-2
x|frequency|y[(1,2)]|||ynet1-2
x|frequency|x:y|||cbase*rbase              # same as x|frequency|x[(1,2,3)]:y[(1,2,3)]|||cbase*rbase

... and so on.
Another important change that should be made is to use the conventional curly brace for set notation, so in net codes should be written as x[{1,2}]: instead of x[(1,2)]:. Currently the curly brace is used for answer count, but the two uses should be swapped. In this way one answer from codes 1 or 2 would be written as x[{1,2}(1)]:.
Due to the required delimitable-nature of the method-part of the view key, it may be prudent to put in place some truncation rules that method names must adhere to. For example instead of frequency perhaps simply f will suffice, especially given that it's so common. for other methods a 6-character limit per sub/method-part (to allow for needed abbreviations like stddev, stderr and so on) would help condense the overall key length and improve readability.
To avoid ambiguity, what is currently the relation part of the view key must always include a colon.
|:| means no conditions placed on either x or y
|x:| collapsed x, no conditions placed on y
|:y| collapsed y, no conditions placed on x
|x:y| collapsed x and y
The new convention means you should never see something like |y:x| because the left-hand side will always describe x and the right-hand side will always describe y.
In accordance with all of these proposed changes, the above view keys would become:
x|f|:|||counts
x|f|:|y||c%
x|f|:|x||r%
x|f|x:|||cbase                      # same as x|f|x[(1,2,3)]|||net1-3
x|f|:y|||rbase                      # same as x|f|y[(1,2,3)]|||net1-3
x|f|x:y|||cbase*rbase               # same as x|f|x[(1,2,3)]:y[(1,2,3)]|||cbase*rbase

However, all of these examples use the same method on x and y, which will often not be the case. Where a different method is used on each, both methods must be named and must be colon-delimited.
In conjunction with the need for descriptive stats to be named using sub-methods, this leads to:
x|d.mean:f|x:|||cmean                # column mean
x|f:d.mean|:y|||rmean                # row mean

Including the change for set notation, block nets also need to appear in discrete x-blocks delimited with a comma, meaning they will change from |x[(1,2),(3,4),(5,6):y to |x[{1,2}],x[{3,4}],x[{5,6}]: This both corrects for ambiguity compared to complex logic and to provide for a comma-delimited relationship between the multiple methods and x/y.
Given the likely eventuality of other block methods the conventions should be similarly lazy, where f|x[{1,2}],x[{3,4}],x[{5,6}]: is effectively shorthand for f,f,f:f|x[{1,2}],x[{3,4}],x[{5,6}]:.
This is more relevant when imagining the needs of a block of descriptive stats, in which case d.mean,d.stddev,d.stderr:f|x: is more meaningful. In any case, parts that are not mentioned explicitly imply uniform application, so as to prevent the need for something like d.mean,d.stddev,d.stderr:f|x,x,x:.
x|d.mean:f|x:|||cmean                # column mean
x|f:d.mean|:y|||rmean                # row mean

effective base
Effective base view keys should indicate a sub-method of frequency and must name a weight-part. What is currently x|frequency|x:y|||ebase should become x|f.eff:f|x:||weight|ecbase. Similarly, an effective row base would be x|f:f.eff|:y||weight|erbase.

The more I think about this the more I wonder if the meaning of relationship as we've understood it until now is defunct, because the colon becomes the link between x/y and their respective methods, especially given examples like x|f|y|||rbase, in which x doesn't need to be mentioned at all but the relationship between x and y is still described.
One option would be instead of:
x-position | method | relationship | relative to | weight | shortname
We could move to:
x-position | method/s | condition/s | relative to | weight | shortname
Since the third part of the view key actually describes the conditions placed on x and/or y as they are fed into their respective methods.

Examples of frequency-only keys:
############################ Counts
x|f|:|||counts

   1  2  3  4  5
1  1  7  3  2  7
2  4  3  5  4  6
3  6  2  4  6  3

############################ Column base
x|f|x:|||cbase

       1   2   3   4   5
cbase  11  12  12  12  16

############################ Column base percentages
x|f|:|y||counts

	a	b	c	d	e
x	9	58	25	17	44
y	36	25	42	33	38
z	55	17	33	50	19

############################ Row base
x|f|:y|||rbase

   rbase
1  20
2  22
3  21

############################ Row base percentages
x|f|:|x||counts

	a	b	c	d	e
x	5	35	15	10	35
y	18	14	23	18	27
z	29	10	19	29	14

############################ Intersection base
x|f|x:y|||base

       rbase
cbase  63

############################ Intersection base percentage
x|f|:|xy||counts

	a	b	c	d	e
x	2	11	5	3	11
y	6	5	8	6	10
z	10	3	6	10	5

############################ Column net
x|f|x[(1,2)]:|||cnet

       1   2   3   4   5
cnet   5   10  8   6   13

############################ Row net
x|f|:y[(3,4)]|||rnet

   rnet
1  5
2  9
3  10

############################ Intersection net
x|f|x[(1,2)]:y[(3,4)]|||base

       rnet
cnet   63

############################ Block net rows
x|f|x[(1,2)],x[(2,3)]:|||cnet

       1   2   3   4   5
cnet1  5   10  8   6   13
cnet2  10  5   9   10  9

############################ Block net columns
x|f|:y[(3,4)],y[(4,5)]|||rnet

   rnet1 rnet2
1  5     9
2  9     10
3  10    9

############################ Intersection block nets
x|f|x[(1,2)],x[(2,3)]:y[(3,4)],y[(4,5)]|||base

       rnet1 rnet2
cnet1  14    19
cnet2  19    19

############################ Effective column base
x|f.eff:f|x:||weight|ecbase

       1   2   3   4   5
ecbase 11  12  12  12  16

############################ Effective row net
x|f:f.eff|:y[(3,4)]||weight|ernet

   ernet
1  5
2  9
3  10

############################ Effective intersection base
x|f.eff|x:y||weight|base

       erbase
ecbase 63

Nested notation
x and y are themselves lazy-notations for x0 and y0, which become explicitly required when the axes are nested.
Here's an example of notation describing column logic on the 2nd x-level filtered by those who answered each of the values in the column on the 1st x-level.
x|f|x1[{1,2}]:|||cnlogic

x0    x1         1   2   3   4   5
1     clogic     2   4   9   8   3
2     clogic     3   2   1   2   4
3     clogic     6   7   3   4   7
4     clogic     3   3   5   1   5

Where conditions are applied on multiple levels, each level should be separated with an >.
x|f|x0>x1[{1,2}]:|||cnlogic

x0        x1         1   2   3   4   5
cbase     clogic     2   4   9   8   3
cbase     clogic     3   2   1   2   4
cbase     clogic     6   7   3   4   7
cbase     clogic     3   3   5   1   5

Other than the explicit x1/x0 notation and the addition of >, all the same rules apply, so the row base for this relationship would be:
x|f|x1[{1,2}]:y|||cnlogic

x0    x1         rbase
1	  clogic     26
2     clogic     12
3     clogic     27
4     clogic     17

Nested notation also applies to relative notation, let's assume the y-axis is also nested and we want percentages based on the 1st y-level rather than the 2nd. In this case the percentages for the first two columns are based  on the y0=1, and the third and fourth columns on y0=2.
x|f|x1[{1,2}]:y|y0||cnlogic

      y0         1     1     2     2
      y1         1     2     1     2
x0    x1
1	  clogic     34    42    74    45
2     clogic     22    75    63    23
3     clogic     58    87    22    36
4     clogic     63    63    15    17

In any case echewing explicit level notation will always be interpreted as the last-level. So if the y-axis had 2 nested levels, relative to y should be interpreted as relative to y1. The same is true for the conditional part of the key notation, where in the above example :y should be interpreted the same way (if y was nested).

This will be resolved by #290.


6.8.10 Release

This PR prepare 6.8 branch for 6.8.10 release:

bump chart and Docker images version from 6.8.10-SNAPSHOT to 6.8.10
remove notices on README that this is a development branch and development branch specific install instructions

Note

remove notices on README that this is a development branch and development branch specific install instructions

This is required because released Helm charts will be packaged from this PR commit including the README files that will be available inside the chart packages and in Helm Hub pages (example: Elasticsearch chart page).
This change will be reverted in the next PR after release when we will bump 6.8 branch to 6.8.11-SNAPSHOT version.

6.8.10 Release changes (to add to GitHub release and changelog):

6.8.10 as the default stack version
K8S 1.16 support in #635 @jmlrt

Elasticsearch

PR
Author
Title

#596
domgoodwin
Elasticsearch secret mount mode

#638
@fatmcgav
Fix issue with readinessProbe causing outages

#639
@coolbaluk
Fix values links in examples/multi/README.md

Kibana

PR
Author
Title

#555
@ramrodo
Add extensible label support on Kibana

#637
@maxkochubey
String/YAML conditions for .Values.{extraContainers,extraInitContainers}

Metricbeat

PR
Author
Title

#622
@jmlrt
Fix deployment upgrade by removing chart label from .spec.selector.matchLabels

#624
@jmlrt
Use deprecated kube-state-metrics-metricbeat.yml when existing

#634
@MaxRink
Fix configChecksum not being set


Magisk hide module problem

I am using magisk Alpha which doesnt have magisk hide features but it has zygisk which has denylist so i deny all permission for root to gms ,and the basic intregity passed but when i install the magisk hide props configure module ,basic intregity failed.

Magisk Alpha is experimental at best and I've not looked any closer at it yet. I'm likely wait until John releases the next Canary before testing stuff closer.
But, there has been reports of the latest Alpha builds causing problems with SafetyNet, so it might be an issue with the new code.
If you could post them, it would be interesting to see the module logs though.
https://github.com/Magisk-Modules-Repo/MagiskHide-Props-Config/blob/master/README.md#logs


fix: rollback to use repository dispatch

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 24.59%. Comparing base (77ede4a) to head (01c5d84).
Report is 1 commits behind head on main.

Additional details and impacted files
@@             Coverage Diff             @@
##             main     #457       +/-   ##
===========================================
- Coverage   77.29%   24.59%   -52.71%
===========================================
  Files          86      119       +33
  Lines        4946    22000    +17054
===========================================
+ Hits         3823     5410     +1587
- Misses       1026    16062    +15036
- Partials       97      528      +431

Flag
Coverage Δ

unittests
24.59% <ø> (-52.71%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[QUERY] Do .NET SDKs consider "Cancelled" a terminal status for LRO

Library name and version
Microsoft.Azure.Management.Avs  3.0.0
Query/Question
This question is regarding https://github.com/Azure/azure-resource-manager-rpc/issues/144 where Cancelled is used instead of Canceled in a large percentage of the specifications. How do the Track 1 and Track 2 SDKs handle LROs that return Cancelled as a  provisioningState?
Some related code I found is here:
https://github.com/Azure/azure-sdk-for-net/blob/4162f6fa2445b2127468b9cfd080f01c9da88eba/sdk/mgmtcommon/ClientRuntime.Azure/ClientRuntime.Azure/CommonModels/AzureAsyncOperation.cs#L45
Environment
No response

Label prediction was below confidence level 0.6 for Model:ServiceLabels: 'Azure.Core:0.5768477,ARM:0.07481458,AutoRest Runtime:0.028152935'

I found 8 services using Cancelled with provisioningState. I'm going to log bugs for the services instead.


Send   ERC20 token error And get token name error

//trans
let fromAddress: Address = "0x65d1d0dfc525aff63aa2ffea0c3256c171b4ee6a"
let toAddress: Address = "0x95171276fda97ba1ff19af8481bf597bbcdfde83"
let amount = try NaturalUnits.init("1.23")
let amount18 = amount.number(with: 18)
let erc20 = ERC20(self.contractAddress)
erc20.options.from = fromAddress
let erc20Result = try erc20.transferFrom(owner: fromAddress, to: toAddress, amount: amount18)
The error is "Failed to fetch gas estimate"
//get token name
let token = ERC20(contractAddress)
let name = try token.name()
The error is notFound
Please help me to solve the issue , thanks

You have an old example of using lib Now we get the name of token now we used ->
Go to https://infura.io/dashboard/ethereum
Create a new project. In new project you will have PROJECT ID
guard let url = URL(string: "https://kovan.infura.io/v3/your PROJECT ID"),  let web3 = try? Web3.new(url) else { return } let w3sTokenAddress = EthereumAddress("")! let st20token = ERC20.init(web3: web3, provider: web3.provider, address: w3sTokenAddress)

Authour of this issue haven't replied, so I suppose it was resolved and thus closing this issue.
To anyone still experiencing similar problems, feel free to reopen it.


Await doesn't work in Angular project

I tried using await and promises in an Angular 16 project, but it always fails with the following error:
Error: [string "..."]:3: attempt to call a nil value (method 'await')
I executed the same Lua code using vanilla JS and Vue, and it worked in both cases.
I created a minimal reproduction where you can check it: link

I did some testing and realized that the reason why it's not working in Angular is because of Zone.js. I'm guessing the difference is in the inner workings of the ZoneAwarePromise object. When I disabled NgZone for the project, the promises started to work.

Fixed on 1.15.1


Picked - Support asynchronous storage writes

File an issue to track the upstream feature "async storage write" - https://github.com/etcd-io/raft/pull/8
Open to comments on whether we should catch it up and if there is a plan.

raft-rs implemented async storage write in https://github.com/tikv/raft-rs/pull/403 three years ago.

@gengliqi Thanks for your information!


Bump CosmWasm to v2.0

Cosmwasm 2.0 is out for a while, getting cosmwasm packages updated is a requirement for any project that depends on osmosis-std to upgrade.

Would be great if prost will get bumped to 0.13 as well


Reading a non-image buffer prints weird error into console but returns a resolved promise

> require('jimp').read(new Buffer('foo')).then((x) => console.log('image', x))
mime must be a string
Promise { <pending> }
> image undefined

It should not print anything as a side effect. Instead the error should contained in the promise.

Have the same issue with 0.2.28. Take a look at this - https://github.com/oliver-moran/jimp/issues/262.


@conda-forge-admin, please add user @adrinjalali

Comment:
No response

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added user @adrinjalali in conda-forge/huggingface_hub-feedstock#27.


ct and eunit for builds

changes in this pr:

tests (src in /test) are now compiled to the appropriate app's ebin dir (but are filtered and excluded from being included in the app file)
bare tests (those that don't belong to an application) are compiled to _build/PROFILE/ebin. i am not sure this is the best place for them and am open to suggestions for where they should be placed
added add_to_profile/3 function to rebar_state for modifying profiles from within rebar
renamed the logdir for ct tests from logs to _logs to better match other meta directories (it could also be renamed _ct probably)

this pr supersedes #190 so it can now be closed if no one objects

this passed both locally and on travis for me under r15b03, could we try rerunning tests?

Should the logs dir be in _build/logs or whatever?

Yea, _build/logs would be good.

Ugh, I didn't mean to merge this.
Lets get a change in to move logs to _build/logs

should i move '_cover' too?

@talentdeficit yeah. Users should have to ignore _build and not much else from us in their gitignore config, ideally.


Update release versioning and tagging

reopened as https://github.com/canonical/ceph-containers/pull/32


unexpected error occured

I was starting Roblox with Bloxstrap but then i got the "an unexpected error occurred and roblox needs to quit" message but when i use the normal Roblox launcher it works fine...

Are you joining a game directly or are you trying to open the desktop app?

Are you joining a game directly or are you trying to open the desktop app?

I was trying to open the desktop app
On Sat, 8 Jul 2023 at 13:08, pizzaboxer @.***> wrote:

Are you joining a game directly or are you trying to open the desktop app?
—
Reply to this email directly, view it on GitHub
https://github.com/pizzaboxer/bloxstrap/issues/363#issuecomment-1627192222,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUEQ4ATVNXJ237KSNAQ3H5DXPFEUPANCNFSM6AAAAAAZ55N24M
.
You are receiving this because you authored the thread.Message ID:
@.***>

What about directly joining a game?

Like by a link or
On Sat, 8 Jul 2023 at 13:10, pizzaboxer @.***> wrote:

What about directly joining a game?
—
Reply to this email directly, view it on GitHub
https://github.com/pizzaboxer/bloxstrap/issues/363#issuecomment-1627194545,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUEQ4AQ6U4Z4BOMYPW3GPPTXPFE3XANCNFSM6AAAAAAZ55N24M
.
You are receiving this because you authored the thread.Message ID:
@.***>

Like, by clicking the play button on a game's webpage.

Oh right…that didn’t work as well…
On Sat, 8 Jul 2023 at 13:25, pizzaboxer @.***> wrote:

Like, by clicking the play button on a game's webpage.
—
Reply to this email directly, view it on GitHub
https://github.com/pizzaboxer/bloxstrap/issues/363#issuecomment-1627212329,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUEQ4ARKXPTIBIKOS7C5IVTXPFGUVANCNFSM6AAAAAAZ55N24M
.
You are receiving this because you authored the thread.Message ID:
@.***>

Have you configured any FastFlags or mods?

Yes , I think I changed it to the “into the future” I believe its called ?
On Sat, 8 Jul 2023 at 14:41, pizzaboxer @.***> wrote:

Have you configured any FastFlags or mods?
—
Reply to this email directly, view it on GitHub
https://github.com/pizzaboxer/bloxstrap/issues/363#issuecomment-1627292204,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUEQ4ATLE34GKQPMQ762KMLXPFPQPANCNFSM6AAAAAAZ55N24M
.
You are receiving this because you authored the thread.Message ID:
@.***>

Is that the only one? Let me take a look at the full list, you can view it by opening ClientAppSettings.json. Just copy and paste the whole thing here.

that also happens to me, its not fixable

i use the normal Roblox launcher it works fine...

Thinking about it a bit more, chances are it's down to files not being installed properly. If you're still there and you're still having this problem, let me know, and I can find out what's going on.

i use the normal Roblox launcher it works fine...

Thinking about it a bit more, chances are it's down to files not being installed properly. If you're still there and you're still having this problem, let me know, and I can find out what's going on.

still having the problem

still having the problem

Are you having it where Bloxstrap doesn't work but Roblox's launcher does?

still having the problem

Are you having it where Bloxstrap doesn't work but Roblox's launcher does?

no, bloxstrap isnt the problem, roblox is

it says that it found an unrecoverable error or just crashes when launching

no, bloxstrap isnt the problem, roblox is

So then this issue doesn't apply to you. See https://github.com/pizzaboxer/bloxstrap/wiki/Roblox-crashes-or-does-not-launch.

no, bloxstrap isnt the problem, roblox is

So then this issue doesn't apply to you. See https://github.com/pizzaboxer/bloxstrap/wiki/Roblox-crashes-or-does-not-launch.

already tried everything

Issue has been awaiting clarification for over a month, closing as stale. If you have anything further to add, just respond and I'll reopen.


Asking for permission make AppState 'change' handler call

Bug
I a trying to request for location permission in Android
but as I call for permission the AppState 'change' handler call. and it act like app was in background
Environment info
react-native info output:
 System:
    OS: macOS Mojave 10.14.6
    CPU: (4) x64 Intel(R) Core(TM) i5-5250U CPU @ 1.60GHz
    Memory: 22.64 MB / 8.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 12.13.0 - /usr/local/bin/node
    Yarn: 1.22.0 - /usr/local/bin/yarn
    npm: 6.13.7 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  SDKs:
    iOS SDK:
      Platforms: iOS 13.2, DriverKit 19.0, macOS 10.15, tvOS 13.2, watchOS 6.1
    Android SDK:
      API Levels: 23, 25, 27, 28, 29
      Build Tools: 27.0.3, 28.0.3, 29.0.2
      System Images: android-28 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom
      Android NDK: Not Found
  IDEs:
    Android Studio: 3.5 AI-191.8<IP_ADDRESS>10548
    Xcode: 11.3.1/11C505 - /usr/bin/xcodebuild
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.9.0 => 16.9.0
    react-native: 0.61.5 => 0.61.5
    react-native-permissions: ^2.0.10
  npmGlobalPackages:
    *react-native*: Not Found

Library version: 2.0.10
here are some codes

    useEffect(() => {
        makeLocationPermission()
        AppState.addEventListener('change', appStateHandler)
        initialRender.current = true
        return () => {
            AppState.removeEventListener('change', appStateHandler)
        }
    }, [scope])

    const appStateHandler = async (state) => {
        if (state === 'active') {
            if (!scope.isGranted) {
                await makeLocationPermission()
            }
        }
    }

expo

It's normal. The permissions alert is not in you application View

@zoontek but it cause bug. how can I handle it.
for my case I want to open Settings page and form the user to manually enable some permissions and when app state is 'active' I want to check whether user enabled that specific permission or not.

You don't need to listen for AppState changes if the result of the permission check is not blocked (because a system alert will appear to ask permission, no need to open settings).
Subscribe to it only if you trigger openSettings (just before calling the function) and unsubscribe when the app regain focus.

I have both case. alert and openSettings. I just fix it with a flag. but seems a little hacky

@zoontek I am not sure if this is entirely true. Re-checking after AppState changes might still make sense as a user can change permissions even if he/she does not use the openSettings call, but by navigating to those settings. Therefore, I would still check for AppState changes.

Same problem for me here, I did it by using a flag too. Little bit tricky from my point of view

On Android, the background state means that the React Native Activity is in background, and not necessary the entire app.
To handle this, I created a package that implements the Android Lifecycle API for React Native: https://github.com/douglasjunior/react-native-applifecycle

Why Use This?
The original AppState API provided by React Native behaves differently between Android and iOS, particularly regarding the background state:

On iOS, the background state signifies that the entire app is in the background.
On Android, the background state indicates that the React Native Activity is in the background, which might not necessarily mean the entire app is in the background.

By using react-native-applifecycle, you can handle these differences seamlessly across both platforms, ensuring that the state background will be dispatched only when the entire app is in background.

Even calling check(PERMISSIONS.ANDROID.ACCESS_FINE_LOCATION) causes background state on Android (it's not necessary to request a permission to see this issue).


Multiple listeners with remote filter don't work

Hi,
I'm using atwho to bind @ char and # char with a remote callback definedwith remoteFilter. But it seems to run only the latest one!
element.atwho({ at: '@', ... , callback: { remoteFilter: ... }});
element.atwho({ at: '#', ... , callback: { remoteFilter: ... }});

Any idea?

Hi @ichord, in regards to this issue, please see my comment here: https://github.com/ichord/At.js/commit/bf938db68ab4c82f0ed885fec602241e38c49191

@jiin please show me the completed configuration. I have a try and it work fine.


[napari-workflows] Access parameters within napari-workflow?

placeholder, I'll update later (e.g. True,True,True,True, in measurement for 3D)

If this is about https://github.com/fractal-analytics-platform/fractal-tasks-core/issues/152, I think that's mostly out-of-scope for Fractal. The user should provide pipelines with correct settings for the resolution levels they want to run things at. We can't know which parameters would need to be scaled when.
If it's about changing other parameters, I'm happy to have the discussion whether those should be modified within Fractal or whether that should be done outside of Fractal :)

TL;DR
This issue was not specially relevant, and can be closed right away. I thought we'd have to validate some inputs (the perimeter=True/False one) to avoid unsafe execution, but actually the napari-workflow function (a wrapper of scikit-image itself) already does that for us.
If access to workflow parameters comes up somewhere else we can open a new issue. I guess the typical answer will be "user is in charge".

The regionprops function that we use as part of workflows has these arguments:
def regionprops(
  image_layer : napari.layers.Layer,
  labels_layer: napari.layers.Labels,
  size : bool = True,
  intensity : bool = True,
  perimeter : bool = False,
  shape : bool = False,
  position : bool = False,
  moments : bool = False,
  napari_viewer : Viewer = None):

On one example (I don't have a reproducible script at hand, but I can recreate it if is useful) running on 3D data and with all arguments set to True led to a memory error (asking for >50G of memory allocation, for the tiny dataset). This seemed weird and I switched to True, True, False, False, False, False, which was sufficient to avoid the error.
At first (and this is the reason for the current issue) I thought that the problem was that perimeter measurement is not allowed for 3D images. Then I realized that the napari-workflows function linked above actually raises a warning about that, and then skips this property. Therefore the large memory usage should have come from some other property (shape, position or moments). I did not dig further to identify it.

Ok, makes sense, thanks for the context! :) They work well on 2D examples, but some may not make sense for 3D measurements :)


Remove rogue ConfigureAwait

We don't do it anywhere else, I assume this is left over
from older legacy

Is because it's calling user code and who knows what they may do?

@benaadams so does https://github.com/aspnet/KestrelHttpServer/blob/557c04c93295d7c6965618eaa66ed9725343af0f/src/Microsoft.AspNetCore.Server.Kestrel.Core/Internal/Http/FrameOfT.cs#L129 and https://github.com/aspnet/KestrelHttpServer/blob/557c04c93295d7c6965618eaa66ed9725343af0f/src/Microsoft.AspNetCore.Server.Kestrel.Core/Internal/Http/FrameOfT.cs#L136

That's all I've got :)

Guessing it doesn't matter as its the outer await that calls user code; rather than an inner one user code calls. Bit early an not had coffee yet :)

Actually can you still specify the scheduler stuff gets run on? Might be more important now?
Yes, it'll be fun to see what people come up with (by shooting themselves in the foot 😄 ). We need to make sure everything runs properly when you run on IO threads if you don't do anything wrong.

@cesarbs already found a problem https://github.com/aspnet/KestrelHttpServer/pull/1829


Fix syntax highlighting

https://github.com/atom/highlights/commit/5a971ac4cfb53a55a0d24dc21e2182d84ed079f4
This got broken by Atom's shadow-dom changes.

LGTM.


Error in New Relic Infrastructure Window agents

Facing the issue and error in New Relic Infrastructure Window agents . Metrics are missing.
time="2023-11-07T07:36:56Z" level=error msg="Integration command failed" error="exit status 1" instance=nri-kubernetes integration=com.newrelic.kubernetes prefix=integration/com.newrelic.kubernetes stderr="time="2023-11-07T07:36:56Z" level=panic msg="failed to discover nodeIP with kube-state-metrics, got error: pods is forbidden: User \"system:serviceaccount:newrelic:nri-bundle-newrelic-infrastructure\" cannot list resource \"pods\" in API group \"\" at the cluster scope"\ntime="2023-11-07T07:36:56Z" level=fatal msg="failed to discover nodeIP with kube-state-metrics, got error: pods is forbidden: User \"system:serviceaccount:newrelic:nri-bundle-newrelic-infrastructure\" cannot list resource \"pods\" in API group \"\" at the cluster scope"\n" working-dir="C:\Program Files\New Relic\newrelic-infra\newrelic-integrations"
Description
Describe the problem you're encountering.
TIP: Do NOT share sensitive information, whether personal, proprietary, or otherwise!
Expected Behavior
No error in the agent logs , metrics should come
Troubleshooting or NR Diag results
Provide any other relevant log data.
TIP:  Scrub logs and diagnostic information for sensitive information
Steps to Reproduce
Please be as specific as possible.
TIP:  Link a sample application that demonstrates the issue.
Your Environment
Include as many relevant details about your environment as possible including the running version of New Relic software and any relevant configurations.
Additional context
Add any other context about the problem here. For example, relevant community posts or support tickets.
For Maintainers Only or Hero Triaging this bug
Suggested Priority (P1,P2,P3,P4,P5):
Suggested T-Shirt size (S, M, L, XL, Unknown):

From the error above this is an issue with a misconfigured ClusterRole object:
level=fatal msg="failed to discover nodeIP with kube-state-metrics, got error: pods is forbidden: User \"system:serviceaccount:newrelic:nri-bundle-newrelic-infrastructure\" cannot list resource \"pods\" in API group \"\" at the cluster scope"\n" working-dir="C:\Program Files\New Relic\newrelic-infra\newrelic-integrations"


Unknown statement syntax when running swiftc with new 5.7 syntax source file

Describe the bug
Got unknown statement syntax when running swiftc with new 5.7 syntax source file, for parsing the syntax tree into JSON.
Steps To Reproduce
Steps to reproduce the behavior:

Create a new Swift app in the Xcode
Write a simple function with the new 5.7 if let syntax

    func testExample() throws {
        let app = XCUIApplication()
        app.launch()

        var name: String? = "Linda"

        if let name {
            print("Hello, \(name)!")
        }
    }

Run swiftc -frontend -emit-syntax test-swift-appUITests/test_swift_appUITests.swift
See the error:

test-swift-appUITests/test_swift_appUITests.swift:32:9: error: unknown statement syntax exists in the source
        if let name {
        ^

Expected behavior
Should get the correct JSON output without error.
Screenshots

Environment (please fill out the following information)

OS: macOS 12.5.1
Xcode Version/Tag/Branch: Version 14.1 (14B47b)
Swiftc

swift-driver version: 1.62.15 Apple Swift version 5.7.1 (swiftlang-<IP_ADDRESS>.3 clang-14<IP_ADDRESS>)
Target: arm64-apple-macosx12.0

Additional context
Add any other context about the problem here.

@AnthonyLatsis just a query, should this be raised on https://github.com/apple/swift-driver instead?

Nah, this looks like a SE-0345 plumbing oversight in libSwiftSyntax.
cc @calda

Thank you so much for your response @AnthonyLatsis
Yeah we moved to latest syntax and now emit-syntax is breaking for us
@calda , @AnthonyLatsis let me know if you need any help or any more information to get this fixed please 🙇

@shreyanshp I am going to close this as not planned because it turns out the -emit-syntax flag is being removed (see https://github.com/apple/swift/pull/62145#issuecomment-1318838637). swift-syntax is validated against the legacy parser, so it won’t have this issue.


Audio tutorial

This PR

Adds load_recording(recording_id: str), load_recordings(), and load_spectrograms() as functions to the dataset class
Adds a jupyter notebook tutorial which loads in all the audio and transcribes a record

@alistairewj it looks like there is a path issue in the CI:
/opt/hostedtoolcache/Python/3.11.9/x64/lib/python3.11/importlib/__init__.py:126: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
tests/test_summer_school_data.py:6: in <module>
    from b2aiprep.summer_school_data import (
src/b2aiprep/summer_school_data.py:46: in <module>
    from b2aiprep.prepare import redcap_to_bids
src/b2aiprep/prepare.py:44: in <module>
    from b2aiprep.utils import _transform_str_for_bids_filename
E   ModuleNotFoundError: No module named 'b2aiprep.utils'

Whoops, forgot to include that file. I moved the transform file to a separate module as it is imported from multiple modules, and it's easier to avoid circular imports that way


Leaves implementation unrecognizable as item by crafttweaker, and ex nihilo sequentia.

Description
As the title says the leaves of all dynamic trees from vanilla to modded in 1.16.5, presumably across all versions do not have an item implementation, which is causing issues when attempting to add crook recipes as well as potentially other issues.
To Reproduce
Install the mod, and attempt to use "/give playername dynamictrees:oak_leaves"
Versions
Include relevant versions below. If this issue relates to add-ons then include their versions too.

Dynamic Trees: 0.10.0-Beta25
Forge: 36.2.8
Java: 1.8.0_301
OS: Windows 10

An item should not be necessary for the leaves, they're only meant as a stand-in block for dynamic tree "multi blocks". Surely recipes like the crook using blocks should require a block name, not an item name?


Add wreq package.

I would like to use that package in codex in place of curl, as this one work on windows platform.
Let see how the CI goes.

Yay!
Also, FYI: https://github.com/bos/wreq/issues/52

Thanks!


Package path ./dist/style.css is not exported from package

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Context:

Browser [e.g. chrome, safari]
Version [e.g. v1.0.0]

Additional context
Add any other context about the problem here.

i need help to solve this issue

Hi. Please consider always taking the issue template seriously. I love helping people who use this library, but this is hard when I get almost no details about what the problem is.
About importing the styles: try importing it like shown in the documentation
<style>     @import "qalendar/dist/style.css"; </style>
If this does not help you, feel free to open the issue again.


Use deploy keys for Add() using app-config-repo

Follow up from #587
Adding the ability to use deploy keys in the above PR proved to be too large a change to make at a single time. Many of the unit tests around the .Add() command rely on specific function calls to be run, rather than checking for the outcomes of those calls.
The work to use deploy keys for external repos will require a significant refactor of those tests, possibly replacing them with new ones to preserve code coverage.

Not supporting two different Git Providers

Related to #581


Ignore chrono advisory till fix is released

There is a Rust vulnerability advisory for the chrono crate that we use in this plugin. Since this CVE has been around for a while and there is no fix in the short term. It's best to ignore it for now as at most it can cause a segfault. This PR adds a config option for cargo audit to ignore this particular advisory.

bors r+


chore: Upgrade reassoc's simplification skills

See zulip discussion
The only lemmas added to reassoc's simplification set are:
Functor.id_obj, Functor.id_map, Functor.comp_obj, Functor.comp_map

all of which are definitional equalities.

Thanks!
bors merge


Migrate funding api to UserAPI

Testing
<Describe required tests: Unit, Integration, Testworld or Functional>
Acceptance Criteria
<What is the acceptance criteria of this ticket?>
Dependencies and affected external components

Bug reports
Expected behaviour
Actual behaviour
Steps to reproduce the behaviour

I think this is a repeat of #1111


Insert four spaces before line content did not transform to html

Open demo insert content in markdown editor like bellow code which lead four spaces before input content, the draft.js editor did not show any html.
    [google](https://google.com)

@Rosey first of all thank you so much for your work. I'm facing the same issue when adding a list with more than 4 space like -      mytext, any update on this issue?


Create a pandas dataframe from an region_map hierarchy

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@1044233). Click here to learn what that means.
The diff coverage is n/a.

:exclamation: Current head 3e30fcc differs from pull request most recent head 9aee2db. Consider uploading reports for the commit 9aee2db to get more accurate results

@@           Coverage Diff           @@
##             main       #6   +/-   ##
=======================================
  Coverage        ?   94.23%
=======================================
  Files           ?       13
  Lines           ?      988
  Branches        ?        0
=======================================
  Hits            ?      931
  Misses          ?       57
  Partials        ?        0

Flag
Coverage Δ

pytest
94.23% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


More python-related ignores

Welp, forgot what I wanted to add here

I think it was supposed to be the full list of ignores github creates for python
That's going to be for later, no time for that now

https://github.com/github/gitignore


Need new Replication API

NuGet needs a new efficient and reliable replication API:

ideally this should be exposed from static cloud storage directly
the protocol should support the ability for multiple clients to maintain their own read cursor position
the protocol should support adds, updates and deletes

In v3 the protocol is called the Catalog.
The gap is that we need a first class, easy to use, client library for dealing with this protocol.

Node.js: https://github.com/NuGet/NuGet.Services.Metadata/blob/master/tests/CatalogTests/Node/collect.js

We have sample code on how to replicate nuget.org using catalog: https://docs.microsoft.com/en-us/nuget/guides/api/query-for-all-published-packages
Will created sample library if asked by users.


You can boot from micro sd crd

on the install pages like e It says you need a usb however you can also boot from a microsd card. if you add this then devices with a micro sd card like the steam deck would no longer need a dock

I added it to the guide but please report future documentation issues here.
Thank you for confirming that it works on the Steam Deck.  I know some handhelds don't like booting from a microSD card.

We don't recommend booting from a micro SD card under any circumstance.


Change Trezor Affiliate link

currently we are using https://trezor.io/?a=myetherwallet.com
we have to change it to https://shop.trezor.io/?a=myetherwallet.com
Please change all occurrences

#2197 should fix this


Show Indexes in Exasol

Is your feature request related to a problem? Please describe.
Indexes are automatically maintained (create/drop) in Exasol
Describe the solution you'd like
Show Indexes including management (manual drop/create -> even if this is not encouraged by Exasol,it is sometimes necessary)
Describe alternatives you've considered
Additional context

was implemented


Find and fix links causing 404 errors when using wget

Links look like this: /%5C%22./misto/85032af2-2893-4ba7-afbc-fe5cdee9a5cb%5C%22
My tip is map component - links are injected into javascript code there.
Looks like it's not causing any issues, but should be investigated in the future.

it should be fixed


action=count is order dependent in Gooey, but the shell alone script is not.

OS: Ubtuntu Bionic Beaver
Python Version: 3.6
Gooey Version: 1.0.0

The argument.parameter action=count is in Gooey order dependent, but the shell alone script is not.
That means for the rather genuine argument verbosity which is often set with a certain amount of v the order "-v, "--verbose" would work for add_argument in Gooey, while "--verbose", "-v" does not!
In the shell alone script the order is arbitrary, and Gooey should work in both orders too, am I right?
Here is an example code. Just start the script with an arbitrary parameter to execute the error throwing version (python test.py e) or without to try the working version (python test.py).
import sys
from gooey import Gooey, GooeyParser
from message import display_message

def get_arguments(parser):
	parser.add_argument(
		"-v",
		"--verbose",
		dest="verbosity",
		action="count",
		default=3,
		help="set verbose output; raise verbosity level with -vv, -vvv, -vvvv from lv 1-3",
	)
	return parser

def get_arguments_error(parser):
	parser.add_argument(
		"--verbose",
		"-v",
		dest="verbosity",
		action="count",
		default=3,
		help="set verbose output; raise verbosity level with -vv, -vvv, -vvvv from lv 1-3",
	)
	return parser

@Gooey(program_name="Order Error Count Demo")
def main():
	desc = "Example application to show that Gooey abbility" \
	 	+ " to handle the action 'count'\nis dependent on the order" \
		+ " of '-' and '--' argument."
	parser = GooeyParser(description = desc)
	if len(sys.argv) > 1:
		parser = get_arguments_error(parser)
	else:
		parser = get_arguments(parser)

	args = parser.parse_args()

if __name__ == '__main__':
	print("Just start the script with an arbitrary parameter "\
		+ "to execute the error throwing version.")
	main()

Fixed!
Thanks for the detailed and runnable example!
It'll be part of the next release. In the meantime, you can access the fix here if ya want: https://github.com/chriskiehl/Gooey/commit/d37508da77a24b2a876436fc33cf767a56d17ce5

Great to hear!


Fix GameUI::createCommandMsgBox() index

Issue #3077

how can i make a popup when i  injected my osiris?

@wemanzoz It just
interfaces->gameUI->createCommandMsgBox("Title of messagebox", "Content of messagebox");
Call it when and where you want to get a popup.

@danielkrupinski Yep, works perfect on Linux too with same offset.

Thanks!


Documentation Website Certificate Expired

Please do not file any more issues regarding this here. It is being discussed at https://github.com/scipy/docs.scipy.org/issues/80.

Closing as issue has now been fixed


Support for multiple managed identities per Kubernetes pod

Is your feature request related to a problem? Please describe.
We are currently using pod managed identities to control access between our workloads in Kubernetes and various Azure resources, such as SQL Server and Key Vault. We have resolved (for the time being) to using a single managed identity per Kubernetes pod, since multiple pod managed identities were not supported yet. It was, however, on the roadmap (Azure/secrets-store-csi-driver-provider-azure#284).
We were just about to make an attempt at a PR ourselves, but then we saw that pod managed identities were being deprecated (Azure/secrets-store-csi-driver-provider-azure#837). Thus, we have now begun looking into migrating to workload identity federation. We wish to ensure that our use cases are supported / can be supported - otherwise we need to rethink. Looking at your current documentation, it seems that there might be a 1-1 binding
between:
Kubernetes pod <-> ServiceAccount <-> AD app / managed identity

Describe the solution you'd like
Once managed identities are supported with workload identity federation, we would like the ability for a pod to use one of multiple managed identities depending on the resource it is trying to access at any given time. For instance:

One managed identity provides read access to a single specific database
Another managed identity provides read access to a single specific key vault
etc.

This enables us to create a limited set of managed identities, each with a very restrictive set of permissions, and dynamically assign them to pods in Kubernetes depending on the needs of each individual pod. The less dependent we are on creating new managed identities for all kinds of permutations, the better in our opinion.
Describe alternatives you've considered
We have considered to instead rethink our model, and create a separate managed identity per pod in Kubernetes (or at least per permutation of permissions). However, we see some issues with this:

Every time we introduce a new workload pod in Kubernetes, we need additional logic to ensure that a managed identity has been prepared for it in Azure.

And in extension, adding additional permissions, or restricting the permissions of a pod, requires actions in Azure and cannot be restricted to e.g. a Helm upgrade on our deployed workloads.

For every new pod that requires access to a key vault, we need to make a new role assignment against that key vault, as opposed to giving read access to a single managed identity.
Knowing what permissions are assigned to a pod in Kubernetes requires inspecting all role assignments on the managed identity in Azure, and is not immediately obvious by looking at our Kubernetes resources.
If multiple pods need access to the same database (we have a lot of those use cases), we need to ensure that each corresponding managed identity has been mapped to a SQL user in that database with appropriate role assignments.

In our environment, this currently requires spinning up Azure functions through KEDA to create such SQL users, and as such it becomes unwieldy to do every time a new pod needs access to a database. If, for instance, we had a single managed identity with database read/write access (for that database), we can give new pods database access through a simple Helm upgrade.

Additional context
We are not against changing our current design, but we would at least be interested in best practices for handling our use cases with workload identity federation in whichever form it is released in. We know that managed identities are not currently supported (#325). When they are, however, is there any chance that it might support some of our needs?

We were just about to make an attempt at a PR ourselves, but then we saw that pod managed identities were being deprecated (https://github.com/Azure/secrets-store-csi-driver-provider-azure/issues/837). Thus, we have now begun looking into migrating to workload identity federation. We wish to ensure that our use cases are supported / can be supported - otherwise we need to rethink. Looking at your current documentation, it seems that there might be a 1-1 binding

https://github.com/Azure/secrets-store-csi-driver-provider-azure/issues/837 issue tracks the deprecation of User-assigned managed identity and System-assigned managed identity access modes only. AAD Pod Identity mode in secrets-store-csi-driver-provider-azure will be deprecated and removed after Workload Identity federation support with managed identity is available: https://github.com/Azure/azure-workload-identity/issues/325.
Workload identity to access keyvault is already supported with the Azure Key Vault Provider for Secrets Store CSI Driver: https://azure.github.io/secrets-store-csi-driver-provider-azure/docs/configurations/identity-access-modes/workload-identity-mode/. That doesn't require the webhook that's provided in this repo. It supports multiple identities and there is no 1:1 mapping.

This enables us to create a limited set of managed identities, each with a very restrictive set of permissions, and dynamically assign them to pods in Kubernetes depending on the needs of each individual pod. The less dependent we are on creating new managed identities for all kinds of permutations, the better in our opinion.

Today, you can use multiple identities with the same pod. The annotation in the service account will be used to inject AZURE_CLIENT_ID env var which can be used default by SDKs. But if you want to use a specific identity based on the resource you are accessing, you can provide the client ID of the managed identity when requesting for a token.
The mutating webhook provided as part of this repo enhances the experience by injecting some of the default env vars used by the SDK. That doesn't mean you're pod is limited to just that single identity annotated in the service account. Your app can provide the specific client ID as part of the token request and you can setup federated identity credential for each managed identity that's used by your workload. The same service account token can then be exchanged for a valid AAD token for the requested identity.

Hello @aramase and thank you for the reply. We understand that pod managed identities are not deprecated as of yet, but the fact that they are already planned for removal means it is not something we wish to dedicate ourselves to at this point if we can avoid it.
So if I understand you correctly, the ServiceAccount annotation we saw in the documentation (azure.workload.identity/client-id: ${APPLICATION_CLIENT_ID}) is a completely optional annotation for ease of use. We are free to skip it, and refer to any other client ID as we wish in our SecretProviderClass or any other token request? As long as a federated identity credential has been set up between our AD and the AKS cluster OIDC issuer, we should be fine with the Azure secret store CSI driver alone?
If this is true, I thank you very much for clarifying the setup for us, and you are free to go ahead and close the issue.

So if I understand you correctly, the ServiceAccount annotation we saw in the documentation (azure.workload.identity/client-id: ${APPLICATION_CLIENT_ID}) is a completely optional annotation for ease of use. We are free to skip it, and refer to any other client ID as we wish in our SecretProviderClass or any other token request? As long as a federated identity credential has been set up between our AD and the AKS cluster OIDC issuer, we should be fine with the Azure secret store CSI driver alone?

That's right! The webhook and annotations as part of this project aren't for the CSI driver. For Secrets Store CSI Driver, the client id configuration is part of SecretProviderClass and no annotation is required. If you're using workload identity for accessing other resources in addition to the Secrets Store CSI Driver, you can leverage the mutating webhook as part of this repo to facilitate setting up the projected service account token volume and other env vars that can be useful for your workload.

If this is true, I thank you very much for clarifying the setup for us, and you are free to go ahead and close the issue.

Thank you! I'll close this issue now. If you run into any issues with using workload identity + Azure Key Vault Provider for Secrets Store CSI Driver, feel free to open an issue here. If you have any questions specifically for the webhook or how to use workload identity, you can open an issue in this repo.


help use ssl

How to open ssl? or SSL is not currently supported ?

You should use a reverse proxy; I recommend Caddy for ease of use.


(rpc&&xa): add rpc interfaces to query transaction and refactor XATransactionManager

Codecov Report

Merging #379 into dev will decrease coverage by 2.41%.
The diff coverage is 5.03%.


Update Trackers section of README.md

The trackers table could include some more tracker <> use case combinations

Closing as addressed in https://github.com/snowplow/snowplow/commit/d4aeb4b296925d48c30a74dd2e7db584bdf03f6b


Update to hugo.IsServer from deprecated .Site.IsServer

Another addition in v0.120.0 was hugo.IsServer. .Site.IsServer is now deprecated and failing pipelines all over.
I wonder if setting a min version for the theme of 0.120 would now be reasonable.

Sorry. I fixed that a long time ago, but forgot to push it.
It's done now.

@rmaguiar  I'm glad I was able to refresh your memory. Thanks!