Support Central

gslitt91
That is only one of many examples....
please compare:
https://www.inseln-der-macht.de/anmeldesystem.html?eventId=200&controller=event&task=individualRegister <= production
with
http://playground.inseln-der-macht.de/anmeldesystem.html?task=register.register&eventId=200 <= playground where you have all logins...
as you can see, the fields are in a total different ordering.

2. Point. I checked now your changes: conditional field "SC Kontingent" is loaded with value "Kontingent 1" but this is not availible any more... this i see also when i try to select something different. But when i just click continue then the booking will be done with a value which is not availible any more (over the limits)

gslitt91

ok ordering seams now to be ok. how can i copy it to production (wich table/columns does i have to save?)

next issue: birthday field is not beeing saved. not from front or backend.
next issue: when i create a booking and like to pay it later. and then change the due value in admin backend... it is not represented in pay now option.
For example booking: IDM-19-T0-SC-D-5726383 should now cost only 1 euro because of admin change.... this is also shown in frontend under my bookings ...?controller=user&task=index so here it is correct.

When I click now to "pay now" i get shown a wrong due (245€)

This wrong value is also send to payment gateway.

gslitt91

So Date filed is fixed,
ordering issue seams to be fixed.
Pay now is only partialy fixed.

So Record: IDM-19-T0-SC-D-2149857 costs original 45 € i modified it in backend so that it costs only 1 € than I used the Pay Now option from frontend like discribed above. Now your fix show me 1 € and this is also given to Paypal... (thats the working halve) when it comes back from paypal as payed ... it seams that he recalculate the price of the record and throw away what ever I modified in backend. So now the record costs again 45 € but 1 € is already paid. Emails are generated also like this with 44 € are open. so consitent wrong Also the paypal transaction number is not stored back to the record... and as there is something still open the record is not marked as paid.

gslitt91
are all 3 bugs from here fixed in 4.2.3 ?

gslitt91 doesn’t work for me

gslitt91
Hi, sorry for this long waiting period, we are just in the last moments of prepering the actual event and before mid of sept, i also cant make any change to production. So what I am searching kind of, is a automatic way, that field ordering and field dependency (conditional fields) are like they was before (v4.0.9) in 4.2.0 you reorded them on my development and i just saved the fields table with rgt and lft and so on column. but when i just copy that table in the fields are maybe right ordered but the condition is not realy working. So can you please explain me, from a DB perspective how the following 3 things are working. in the actual version:

1.) Where do you say this is a dependent field from that option of a other one.
prefix_dtregister_fields.parentId, prefix_dtregister_fields.selectionValues and prefix_dtregister_fields.level .... but it seems that i missed something
2.) How is the ordering done:
I thought prefix_dtregister_fields.ordering was the old one
Now it must be prefix_dtregister_fields.lft, prefix_dtregister_fields.rgt, prefix_dtregister_fields.level... but something seams to be missing
3.) then how is a field mapped to an event. I tought:
db43112.j25_dtregister_field_event

so even with bringing back all mentioned column it looks not like before. so which columns did i missed?