bug dynamicklink task not yet accepted

Hoes does the user clicks have an impact if the process flow hasn't progressed further?

Were the user changes reflecting in the model as well in this case? I think that should not be the case. Clicks will not be counted if task is not accepted.

You are right I will better explain the use case:

Suppose that you have a gridlayout where the number of the rows depends on a ri or on a local variable.

In this grid you can add and remove rows and once the form is submitted the ri or local value will be saved on a pv that will update a db table.

Now

If one user, without accepting the task, can add or remove rows the result is that the ri or local variable will be updated.

When another user will accept the task the rows of the grid will be already modified (added or deleted) by the other user that has not accepted the task. 

The final result is that the data will be updated by a user that has not accepted the task

This use case is quite common working with gridlayout on Appian

No, that is not possible.

I tested the same scenario.
I copy pasted this below editable grid to a user input task form:
https://docs.appian.com/suite/help/19.1/recipe_add_edit_and_remove_data_in_an_inline_editable_grid.html

and assigned it to a group.

I logged in and clicked dynamic link twice, added two rows... from there I'm assuming you just click on Tasks tab again or leave it without accepting task.

Checked with another user login... it's not reflecting at all. Appian did not allow any changes to be reflected here.
There is no issue/bug here, I request you to please replicate this once and let me know.

Yes you are right, it works.

I have a similar use case where the bug still remain (if you use an a!deleteFromDataStoreEntities or a!writetoDatastoreEntity in the a!save of a dynamicLink) but I will open another discussion

Hi,

I just ran into this same issue as you, where a dynamic link is active before a task is accepted and was planning to use a a!writeToDataStoreEntity.   I suppose I could refactor my design to persist the data differently however wanted to leverage same user interface expression in other contexts which don't need the extra complexity.

Curios if you had entered an Appian support ticker for this?

I believe the solution to this use case is rather simple.  Create a rule input i.e. ri!taskOwner, and in the user input task configuration, configure that input to accept tp!owner, which will not populate until a user accepts the task.

Then, in the local variables definition, set up a chain of variables (depending on how robust you need/want it to be) - i would suggest starting with local!isAccepted: not(isnull(ri!taskOwner)), followed at least by local!enableDynamicLinks: and( local!isAccepted, local!otherConditions /* etc */ ), and then for all dynamic links on the form, use (or at least include) local!enableDynamicLinks to set whether the links show up at all.