-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle template formulas in the report title field #33131
Comments
@thienlnam Whoops! This issue is 2 days overdue. Let's get this updated quick! |
@thienlnam Whoops! This issue is 2 days overdue. Let's get this updated quick! |
@thienlnam Huh... This is 4 days overdue. Who can take care of this? |
Still need to investigate |
@thienlnam Huh... This is 4 days overdue. Who can take care of this? |
@thienlnam Still overdue 6 days?! Let's take care of this! |
@thienlnam 10 days overdue. I'm getting more depressed than Marvin. |
1 similar comment
@thienlnam 10 days overdue. I'm getting more depressed than Marvin. |
@thienlnam Huh... This is 4 days overdue. Who can take care of this? |
No update: Going to pass this back with the OpenDraftWorspaceRequest call |
@thienlnam Eep! 4 days overdue now. Issues have feelings too... |
Will work on this today |
As I look into this, I am thinking of just passing back the formula title as the defaultValue on the reportField text_title. That should make it the most straightforward implementation. The only drawback is if we are offline, it will pull the last stored value which would be inaccurate (we could probably negate this with some offline UI handling that we would need to add in the offline required case anyways) What do you think? |
Alternatively, I could store the value in another NVP policyDefaultTitle_ |
I think adding it in My recommendation here would be to let the |
Are you thinking in the future scenario where we allow the user to update the formula via NewDot? I was thinking the formula is not actually necessary in the FE because we aren't adding the ability to decode all formula values optimistically.
I think this is ideal - and should happen automatically once openReport is called (should pull down the report title). The main issue is what happens with this draft report. OpenDraftWorkspace doesn't currently pass a reportID. Perhaps we can add the optimistic reportID to that and have the API send a pusher request to set the report title in onyx? |
Hmm actually, it's not like you set the report title during the creation of an IOU. Maybe we can do nothing here - if we're offline and the report title is enforced, we will make the field non-editable. Otherwise, it will default to the formula but can be updated, then once the user comes back online it will automatically update to the report field unless it was modified |
This issue has not been updated in over 15 days. @allroundexperts, @thienlnam eroding to Monthly issue. P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do! |
We decided to do nothing here - #33131 (comment) |
When loading report fields, on app init we load the report fields for the primary policy
However for report titles, which can have a formula which contain things from here. There can be items that would only be known from the BE and so there is not a good way to handle this entirely optimistically on the FE.
Once the report is created, the changed report title should already be handled (as it pulls the report name from the BE on OpenReport) but the issue is in the draft report state.
In the draft report,
The text was updated successfully, but these errors were encountered: