CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2019-08-21T16:48:10Zhttps://lab.civicrm.org/dev/core/-/issues/1061Bad popup on update recurring screen2019-08-21T16:48:10ZeileenBad popup on update recurring screenWe are seeing a popup when checksum users attempt to update a recurring contribution.
![Screenshot_2019-06-12_at_18.50.39](/uploads/85512b40438dcd0e198fddc51dd64c00/Screenshot_2019-06-12_at_18.50.39.png)
This appears to date back to M...We are seeing a popup when checksum users attempt to update a recurring contribution.
![Screenshot_2019-06-12_at_18.50.39](/uploads/85512b40438dcd0e198fddc51dd64c00/Screenshot_2019-06-12_at_18.50.39.png)
This appears to date back to March 2018 when custom data was added to this form (by @mattwire ) - which means we don't need to target the rc & I'm inclined to focus on 'the right fix' on master.
Fundamentally we have a backoffice form that is being exposed for front end users. I have personally proposed doing similar to the 'Add Payment' form recently so it probably bares a little thought. In this case the custom data is not accessible to checksum accessors of the page & superficially the problem is not that it is not available but that it is noisily not available.
I feel like at a conceptual level we probably want to either
1) say front end forms are front end forms and back end forms are back end forms and never the twain shall meet or
2) set the front end form flag whenever a both-use-form is accessed with a checksum
In terms of the custom data I feel the safest option is just to say 'don't expose custom data on both-use forms to users without Access CiviCRM'. If people want to this might not be the right form approach for them - they can actually probably intervene by hook but the risk of exposing inappropriate custom data fields seems real.
This probably also impacts on theming & provides an obvious way not to present un-themed versions of these pages (@seamuslee @totten )5.17.0