Url datatype

[sadaf895]

closes: #2460

[sleidig]

It seems like you didn't test this in the app yet 😉 It didn't work for me because we forgot to register the components (see my commit now).

The component still has some issues. Test it while keeping the Developer Console open and see various errors. I think it is not "allowed" to mark a <a with matInput, this only works for <input as far as I know.

[sleidig]

EditFileComponent might have some logic applied that allows users to click even on the disabled field. Maybe you, @Abhinegi2 and @sadaf895, can look at this together to finish this PR

[Abhinegi2]

@sadaf895 I made some modifications to allow user clicks even when the form is disabled. I also added test cases and updated the cursor styling. Please review these changes and let me know if any functionality is missing.

To enable user clicks while the form is disabled, I followed this approach(which we already following in EditFileComponent ):
(https://stackoverflow.com/questions/3100319/event-on-a-disabled-input/32925830#32925830)

[sleidig]

Code and functionality looks pretty good already 🙂

From functional testing a few suggestions to polish this further. Can you take these points up again, @sadaf895 ?

• in the list view, the link is not working and instead the details view of record is loaded. If clicking exactly on that link, I would like to instead open the external url in a new tab (@Abhinegi2 has implemented something similar only last week)
• The form field's link text should look a bit more like a clickable link. I suggest we give this an underline styling or maybe underline on hover (i.e. maybe giving this our global "clickable" css class)
• if the value is not a valid url (e.g. just some random text), this anyway opens a new tab to our app. In such a case the link should not be clickable (and not styled like a link
• if I put a URL without leading http or https it is not opened as an external link. Probably we should prefix that automatically if it is required to work as links. Maybe we can use a similar design to the screenshot below, where "https://" is always automatically prefixed and cannot be changed?

If unsure about design, do ask for feedback on our Slack

[Abhinegi2]

@sleidig regarding the valid URL validation point, I have two approaches in mind. Which one should we follow?

• Add a new validator similar to isUniqueId and validEmail, as we did for the readonlyAfterSet validator.
• Follow the approach Sadaf already implemented, where a new method is added in EditUrlComponent to check for a valid link.

[sleidig]

@sleidig regarding the valid URL validation point, I have two approaches in mind. Which one should we follow?

• Add a new validator similar to isUniqueId and validEmail, as we did for the readonlyAfterSet validator.
• Follow the approach Sadaf already implemented, where a new method is added in EditUrlComponent to check for a valid link.

I think the "EditUrlComponent" should automatically bring that validation without anyone having to additionally configure a validator. To achieve that, maybe a method in the component is easier. But whatever gives the desired result is good.

It may be easier also to implement a ValidatorFunction (like isUniqueId) and always add it to the formControl within the component. I am not sure how to integrate a simple method within the formControl validation process otherwise.

[sleidig]

unit test cases to implement for this functionality:

• it("should be invalid for value that is not a complete URL": input value: "example", expected result: false
• it("should be valid for empty value": input value: "" or input value: null (test both), expected result: true
• it("should be valid for url-like value": input value: "https://example.com", expected result: true

[sadaf895]

@george-neha Can you please check the functionality as a user's perspective and share your feedback on it?

[george-neha]

As a user, I will do either of the two things:

1. type out the website link (more probable),
2. copy and paste the link the URL.

I feel adding a prefix to the website field with https:// and letting the user type in the website name would be more user-friendly. (see image below)

In scenarios where a user will copy-paste the URL. Would it be possible to truncate the additional https://? What do you think @sadaf895

[sadaf895]

As a user, I will do either of the two things:

1. type out the website link (more probable),
2. copy and paste the link the URL.

I feel adding a prefix to the website field with https:// and letting the user type in the website name would be more user-friendly. (see image below)

In scenarios where a user will copy-paste the URL. Would it be possible to truncate the additional https://? What do you think @sadaf895

@george-neha Can you now check the functionality? Any improvement or modification is needed?
@sleidig @Abhinegi2 Can you both also please check the updated functionality or any feedback you want to give regarding this?

[github-actions]

Deployed to https://pr-2646.aam-digital.net/

[Abhinegi2]

@sadaf895 While testing, I found a UI glitch. Here’s how to reproduce it:

• Enter or paste any website URL in the field (e.g., https://www.talisman.org/tao/).
• Try deleting the URL one character at a time. The https:// prefix doesn’t get removed and keeps reappearing in a loop.

However, if you select(complete url) and delete the entire url at once, it works correctly.

Also, I think using a fixed matPrefix would be a better choice, as we are already using it in edit-publicform-route.component, instead of replacing and updating the text.

[Abhinegi2]

@george-neha could you test it again, and let me know if you have any suggestions

[sleidig]

This is not properly usable yet, unfortunately ...
Adding and deleting parts of the prefix creates a number of weird results and issues.

I think we should maybe spell out sensible behavior and test cases for these edge cases of editing:

• trying to delete part of the prefix as a user
• supporting something other than https (just http, for example)

for example, when trying to delete the first letter of the "https" in the field, it is resulting in "https://ttps://aam-digital.com" (just adding the full prefix to the front again)

---

Clicking links seems to work very well now, however 👍

Only the cursor here should be a pointer to indicate clickability:

[sadaf895]

Test Cases for Editing a Website URL:

• Entering a valid URL
  • Input: http://example.com
  • Expected Output: URL is saved and displayed as a clickable link.
• Editing an existing URL
  • Given: http://old-site.com
  • Action: Change to http://new-site.com and save.
  • Expected Output: New URL is displayed and clickable.
• Clearing an existing URL
  • Given: http://example.com
  • Action: Remove the URL and save.
    • A: select all text and delete
    • B: click to put cursor at end of text and hold "<-" delete key to delete character by character
    • C: click to put cursor at beginning of the text and hold delete key to delete character by character (from left to right)
  • Expected Output: The field is empty after saving.

[sadaf895]

list of issues need to be fixed

• for any changes made it need to click the save button twice
• if I delete any character/letter of "https://," then the system is auto-creating the precursor of http:// resulting in a website link http://https:/snuniv.in
• invalid URL ka functionality is now working only after i click on save and click on edit again.

[sleidig]

After discussing the problems giving users confusing results when changing the prefix, we decided the following should be the behaviour:

• typing / pasting something: if without "http://" or "https://" prefix -> immediately add "https://" automatically
  • if the first entered letter is "x" (for example) -> show "https://x"
  • if the first entered letter is "h" -> show "https://" (not "https://h")
  • if the first letter is a whitespace " " -> trim that and show "https://"
  • if the value (pasted) is a url starting with "http://" -> do not add a prefix and keep the value as it is
  • if the value (pasted) is a url starting with "https://" -> do not add a prefix and keep the value as it is
• changing an existing value: do not "accept" changes that "break" the valid prefix
  • changing any part after the "://" -> just do the change without changes (trim whitespaces at the end)
  • deleting any letter of the "https://" (e.g. new value "htps://google.com") -> revert back to the valid "https://" (e.g. "https://google.com")
  • changing from "https://" to "http://" (e.g. new value "http://google.com") -> accept new value (e.g. "http://google.com")
  • adding/changing any letter to the prefix: e.g. "httpx://google.com" -> "https://google.com"
  • "httpS://" -> "https://" (but not important because URLs are case insensitive)