You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Differentiating provisional and annual returns is really necessary. When "check if provisional" is on, this is quite easy. But since the action takes quite a bit longer to run when this setting is enabled, a faster alternative would be nice.
Describe the solution you'd like
It is somewhat possible to deduce if returns are provisional by looking at the "return applied date" column in the return history table. Thus, showing this column when "check if provisional" is disabled would allow the user to still tell if returns are provisional without the performance hit.
This is only a partial implementation of #158. Since the client action system isn't really setup to allow outputs to read their corresponding action's inputs, always showing the column will have to do for now.
This is partially fixed by a8efe58. Due to a technical limitation, columns in an action's output can't be dynamically added based on its input. Until that is addressed, the "return applied date" column will always be shown.
Is your feature request related to a problem? Please describe.
Differentiating provisional and annual returns is really necessary. When "check if provisional" is on, this is quite easy. But since the action takes quite a bit longer to run when this setting is enabled, a faster alternative would be nice.
Describe the solution you'd like
It is somewhat possible to deduce if returns are provisional by looking at the "return applied date" column in the return history table. Thus, showing this column when "check if provisional" is disabled would allow the user to still tell if returns are provisional without the performance hit.
Additional context
#153
The text was updated successfully, but these errors were encountered: