Activities of "AidanCostcoAU"

We have been running our applications (core with angular) on IIS webfarms (with Redis cache), with round robin request routing. From an angular app this has been fine, however we started using Hangfire, and regularly need to access the /ui portal into that. We have found that this does not play well with the webfarm as we want to use it. With the current request routing, it is near impossible to authenticate and reach the underlying /ui sites. Right now, we have converted to client affinity which allows the /ui to work, but defeats the intention of our load balancing. I suspect the /ui authentication path is using data which is not kept in the shared cache (redis), so underlying links are not authenicated when requests cross servers. Any guidance to fix (or an actual fix) would be helpfull. thanks

We are interested in using HangfirePro with the framework (rather than the free version). Haven't tried anything yet, but interested to know if anyone else has gone down this path? Maybe an expansion to the Abp.Hangfire interface?

Just starting a migration to 7.7.2, and looking at our custom RAD tool template merges, and noticed the change in usage of the ObjectMapper. Interested in the reason for the change, so we can decide whether we will follow this in our custom template.

We have been scaling out our user base, and observed a performance issue impacting Authenticate. It appears that every user logon is adding a row to the AbpUserTokens table, and as this table grows the time taken for that user to Authenticate also increases. Once there are more than a few thousand rows, the delay can move into seconds (we have seen up to 15 secs before we located the issue). If we clear the user's rows in the table to a small count, then performance comes back. The users in question are internally defined API users, although we do have some external google users.

What is the intent of this table (none of the rows I saw have anything in Value column)? Is keeping history intended?

Hi,

We just learnt that Swashbuckle v4 no longer builds unique OperationId's in the swagger Json. Previously the operationid was a concatentation of the uri, method, and http type.

The RAD tool is still generating operation names which are not unique (such as GetAll, Delete etc), so these now flow through to non-standard swagger json, which cannot be consumed by other tools.

I can override templates, but please update the base templates.

for existing/regen I should offer some options:

1. generate globally unique method signatures (but will break existing API clients)
2. leave the method signatures the same, but add the swashbuckle aware annotations which render the published operationid as unique - I think this might allow compatibility with existing API clients
3. implement a swashbuckle document processor to achieve the unique operationid's

thanks

When we attempt to navigate to an external url via a side displayed menu, we get routing errors along line of: RROR Error: Uncaught (in promise): Error: Cannot match any routes. URL Segment: 'app/admin/ui-customization' Error: Cannot match any routes. URL Segment: 'app/admin/ui-customization' at n.noMatchError (main.930f82e22f6453f8bf6a.js:1) at l.selector (main.930f82e22f6453f8bf6a.js:1) at l.error (main.930f82e22f6453f8bf6a.js:1) at l._error (main.930f82e22f6453f8bf6a.js:1) at l.error (main.930f82e22f6453f8bf6a.js:1) at l._error (main.930f82e22f6453f8bf6a.js:1) at l.error (main.930f82e22f6453f8bf6a.js:1) at l._error (main.930f82e22f6453f8bf6a.js:1) at l.error (main.930f82e22f6453f8bf6a.js:1) at l._error (main.930f82e22f6453f8bf6a.js:1) at P (polyfills.fb7ef23d4a7cab2845b3.js:1) at P (polyfills.fb7ef23d4a7cab2845b3.js:1) at polyfills.fb7ef23d4a7cab2845b3.js:1 at t.invokeTask (polyfills.fb7ef23d4a7cab2845b3.js:1) at Object.onInvokeTask (main.930f82e22f6453f8bf6a.js:1) at t.invokeTask (polyfills.fb7ef23d4a7cab2845b3.js:1) at e.runTask (polyfills.fb7ef23d4a7cab2845b3.js:1) at g (polyfills.fb7ef23d4a7cab2845b3.js:1) at e.invokeTask [as invoke] (polyfills.fb7ef23d4a7cab2845b3.js:1) at m (polyfills.fb7ef23d4a7cab2845b3.js:1)

which refer to the last successful internal view displayed

If we use any of the top menu templates, the external links still behave correctly.

We have had issues with the templates not generating the same form of camelCase field names in html code as are in the services definitions, requiring hand editing of the RAD tool output. (geneerated was xBIG_ONE vs xbiG_ONE required for typescript match)

Now, we are attempting to move to 5.5.2, and the RAD tool has been updated (1.5.7). Now, there are major changes to table html code particularly, but most concerning is that all the field names which were at least camelCase before are now ALL lowercase, which is a bigger pain. Also some filter naming has changed (but not all).

Can you give us proper control of the name casing in the tool? , or otherwise get the tool to match the swagger driven service code.

thanks