In add-links milestone, link value is not cleared when adding the next link

[maxceem]

In add-links milestone when adding links, link value is not cleared when adding the next link https://monosnap.com/file/BhZHXUtmnBYPpzqtuHPElbNGvwi7WE

How to reproduce

1. In the add-links milestone add one link.
2. When adding the second link value will be empty as expected.
3. But when adding the third link or more, link value will be already filled with the previous value.

Update
Also, I've noticed, that after adding the first link, form to add a link is closed.
But after adding the second link, for to adding the next link is being kept open with the value of the previous link.

Please, clarify, if keeping form open for adding the next link is a desired feature or no.

Aha! Link: https://topcoder.aha.io/features/TCCONNECT-394

[vikasrohit]

@maxceem It turned out a feature for me when I was trying test things in dev because it makes it fast. 😬 However, I am thinking can it be actually a feature for copilots and managers as well? e.g. when they are adding design links which only differs in their ids i.e. the base urls remains same e.g. http://marvelapp.com/8a94680/

fyi @acshields @vic-topcoder

[RishiRajSahu]

@maxceem I am also in favour of keeping it default populated with last link

[maxceem]

@RishiRajSahu ok do you think we just leave everything as it is, or make it same for all the cases:

1. Currently in add-links milestone link value is refreshed with empty after adding the first link. Only after adding the second one it, value keep staying there. Should we make it since first link? Or just leave it for now as it is.
2. We also may add links in old-style checkpoint-review and final-designs if links were not provided be previous add-links milestone. Should we make the same behavior for them or leave them as they are for now? Note, that unlike add-links milestone in checkpoint-review and final-designs milestones links are being send to the server after every link, while in add-links milestone links are being added only client-side and they are send to the server all together when we press submit button.

[RishiRajSahu]

Currently in add-links milestone link value is refreshed with empty after adding the first link. Only after adding the second one it, value keep staying there. Should we make it since first link? Or just leave it for now as it is.

if this is the case, we should either keep it since first link or not at all.

We also may add links in old-style checkpoint-review and final-designs if links...

Yeah there are multiple places where we add design links, not sure if keeping the same behaviour at all places will be a good UX

@vic-topcoder @acshields thoughts ?

[vic-georgiev]

Keeping the value of the link makes it error-prone; users can create a link without updating the link ID. If we're building a feature to add Marvel prototypes what would be a better approach is to remove the repetitive part of the URL, and just accept the Marvel project ID. As sharing a link is easier than copy-pasting the project ID, I would rather not repeat the URL value through adding a link, or make sure there's no ID - I don't want to add duplicate URLs. The goal is not to go quickly through the link adding process, but to make sure we can add the correct project IDs.

@acshields - pulling you in the conversation - the link is very important and there are not clear requirements for reusing the same project for review and final design variant; and when working with multiple resolutions designers tend to create multiple projects; not clearing the URL creates high risk of copy-paste errors or not recognizing the form was not entered correctly. We do increment the user-friendly design option name and I would like that behavior to continue, as this is very helpful, but always clear the URL for adding a new field.

[vikasrohit]

Considering the complicity involve in enabling the type specific link acceptance, as @vic-topcoder suggested, I would rather go for clearing the URL when user adds a new link i.e. just simply fix the original issue.

fyi @acshields @RishiRajSahu

[maxceem]

@RishiRajSahu Fixed in PR #2664