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
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.
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:
thanks
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?
As I see it now, if a token holder calls Logout, then related entries in this table are cleared, but the entries are left behind whenever connections are simply terminated.
Please correct me if I am wrong, but it should be safe to schedule a data maintenance task to remove any records referring to tokens which have clearly expired?
OK. i'll do that.
I think you are on the right track with your comment on 1538.
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.
It looks like GetAll and Get....ToExcel have similar changes
This is how a snippet of code looks in our custom 6.8 GetAll server code looks today (which uses ObjectMapper):
var results = (from o in selectedGIFuelTransactionTrackings
select new GetGIFuelTransactionTrackingForViewDto() { GIFuelTransactionTracking = ObjectMapper.Map<GIFuelTransactionTrackingDto>(o)
})
This is a similar part of the code generated in 7.2.2, which shows the field by field mapping:
var giFuelTransactionTrackings = from o in pagedAndFilteredGIFuelTransactionTrackings
select new GetGIFuelTransactionTrackingForViewDto() {
GIFuelTransactionTracking = new GIFuelTransactionTrackingDto
{
SourceTran = o.SourceTran,
Location = o.Location,
ValidationStatus = o.ValidationStatus,
TranSeqStatus = o.TranSeqStatus,
FCCSeqStatus = o.FCCSeqStatus,
PreAuthAmtStatus = o.PreAuthAmtStatus,
STANStatus = o.STANStatus,
SiteIdStatus = o.SiteIdStatus,
PumpStatus = o.PumpStatus,
HoseStatus = o.HoseStatus,
GradeStatus = o.GradeStatus,
PriceStatus = o.PriceStatus,
VolumeStatus = o.VolumeStatus,
SaleAmtStatus = o.SaleAmtStatus,
SaleMathStatus = o.SaleMathStatus,
MemberIdStatus = o.MemberIdStatus,
PANStatus = o.PANStatus,
Annotation = o.Annotation,
Updated = o.Updated,
FuelSystemType = o.FuelSystemType,
Id = o.Id
}
};
Looking at our checkin history the change to the base AppServiceClass MainTemplate.txt appeared around July.
thanks for that We haven't seen that particular error (yet), but will follow your changes to be safe.