Ends in:
0 DAY
22 HRS
37 MIN
52 SEC
Ends in:
0 D
22 H
37 M
52 S

Activities of "armanozak"

Answer

Hi @dmeagor,

The apiName property in generated services are collected from the remoteServiceName property of each module in the /api/abp/api-definition response. The response looks like this:

{
  "modules": {
    "identityServer": {
      "rootPath": "identityServer",
      "remoteServiceName": "AbpIdentityServer",
      "controllers": { /* controller definitions here */ },
    },
    "types": { /* type definitions here */ }
}

The --api-name parameter, on the other hand, points to the setting in the environment.ts file we should use to fetch /api/abp/api-definition response from. This parameter is useful when building a module and is usually omitted or passed as default when developing apps.

One helpful tip: You can make the CLI ask you questions by running abp generate-proxy --prompt. It then explains what each parameter is good for.

Hi,

Changing only responseType won't work. Except for the project name and the issuer address, your oAuthConfig should look exactly like I shared.

Apart from that, your Angular app should have 2FA support at v3.2, but I don't know about backend. My colleague may help you with that.

Answer

Hi tomasz.lewandowski@neuca.pl,

Yes, there is a bug, but it isn't because of the dot in the solution name. The proxy generator tries to resolve any types with the keyword "System" in it. It apparently cannot resolve the types properly when the solution name ends with the word "System" (and has a dot in the solution name). ~~We will fix it quickly.~~ ~~There is an open PR for this now.~~ Fixed.

Hi,

Have you tried the setting I shared with you?

Hi,

Yes, the Angular app is a single-page application. So, the web server that runs it should be configured to redirect all routes to the index.html file. Please read this section in our documentation and check the official Azure library for deployment.

Please let us know if this answers your question.

Answer

Hi @gvnuysal,

The code is generated correctly by the Suite and the behavior you see is normal.

e alone is not a number in JavaScript or the browser. Therefore, it is not a valid input all by itself. That doesn't mean you cannot use e in number inputs. For example, 125e-5 (or 1.25e-3) is a perfectly valid input.

Hi alexander.nikonov,

The problem here was the use of extensible components even when the component was replaced. This is completely different from your issue. Please open a new question and we will do our best to help.

Answer

Hi sgal,

We can reproduce the error you got with Node v15 and npm v7, but these are not the versions we support. Angular CLI has known problems with these two versions and we do not know when they will be ready to use.

Could you please try with Node v14 and npm v6?

Thanks.

Hi,

I have tried your scenario and could not reproduce the problem. Suite generated the Angular UI successfully.

Hi hilal.aksoy,

You can set the disabled property of the component to true. Here is an example:

<abp-lookup-select
  [disabled]="true"
  cid="authorIdFilter"
  [getFn]="service.getAuthorLookup"
  [(ngModel)]="filters.authorId"
  [ngModelOptions]="{ standalone: true }"
></abp-lookup-select>

Please note that, if created by ABP Suite, there are two instances of abp-lookup-select on the same page: one inside the create/update form and another one in the advanced filters.

Showing 91 to 100 of 107 entries
Made with ❤️ on ABP v9.1.0-preview. Updated on December 05, 2024, 12:19