[Link Checker GUI] Improve Emails and phone number table

[MizukiTemma]

Short description

This PR improves the link table for E-mails and phone numebrs.

Proposed changes

• Add a new sentence between the tabs and table
• Rename column "URL" to "Email/Telefonnummer Verlinkung"
• Add "E-Mail/Telefonnumer auf allen Seiten anpassen" next to the edit icon
• Add a placeholder text "Hier neue E-Mail/Telefonnummer einfügen" to URL replace field instead of actual URL
• mailto: and tel: are hidden in the table list
• mailto: and tel: are auto-added if not given when changing the URL (add "mailto:" if "@" is included, add "tel:" if the new value consists of only number and "+")

Side effects

• Logic Change in edit_url_form.py to accept URL input without "mailto:" or "tel:"

Faithfulness to issue description and design

There are no intended deviations from the issue and design.

• Renaming "Quelle" to "Wo steht der Link" is to be done by [Link Checker GUI] Improve link source column #4516
• Columns "SSL", "Anker", "Code", and "Status" are removed, potential conflict with [Story]: Declutter "invalid links" table view #4458
• Renaming of tabs (Email Lins -> Alle E-mali links and Telefonnummern-LInks -> All Telefon-Links) will be implemented in [Story]: Improve and declutter the display of different link table views #4469

How to test

• Compare the new GUI with the design
• Add some URLs into pages, events, places
• Replace them with valid or invalid values

Resolved issues

Fixes: #4464

---

Pull Request Review Guidelines

[m0ndra]

@MizukiTemma Some things I found while reviewing the design (not sure if these will be implemented in other issues):

• I still see the English texts in the German version
• The table column order is still LINKTEXT and then QUELLE, but QUELLE should be first and then LINKTEXT on the right side
• When I change a telephone number, a %20 space gets included in the link which breaks my number and makes it unusable

• when I change an email or phone number, I'd love to have a more specific success message, see the design here and here

[MizukiTemma]

@m0ndra

Thank you for review 😸

When I change a telephone number, a %20 space gets included in the link which breaks my number and makes it unusable

This is an existing logic of phon number formatting which is curretly used for the contact feature. As we do not force users anymore to enter tel: and mailto:, we need a such formatting here too.

input 0123456789 gets automatically converted to ``

When this contact is enbedded as card:

the code behind is like this:

This logic is re-used in this PR. The link is working even with %20inserted.

I recommend to open a new issue, if we want to fix it. The original issue is about GUI improvement, not a logic change (and I'm agaist making a new function or patch on the existing formatting only for this adjustment in this issue).

[MizukiTemma]

The table column order is still LINKTEXT and then QUELLE, but QUELLE should be first and then LINKTEXT on the right side

I'll include it in #4516 . It goes there cleaner.

when I change an email or phone number, I'd love to have a more specific success message, see the design here and here

Fixed.

It's no one's fault but let me complain one thing:
I thought those two points above are to be implemented in one of the other issues as not explicitly stated in the acceptance crearia👁️ It's really hard to distinguish which changes belong to which issue: one can implement "all" changes visible in one of the design pages which is relavant to the current issue, but then a PR grows up at the end to include almost everything. This hits us hard in this issue series especially, because we do not have 6 different tables for 6 link categories, but all link categories share one table base (with a list of different links to display). So if you change for example a column name, it wll be changed in all categories. Messages like "URL/Email/Phonenumber was successfulyl replaced" and "Links were successfully marked as verified", "Verification was revoked for the links" are managed in one function and because of this my intuition was to fix it rather in #4469

[MizukiTemma]

@m0ndra

I still see the English texts in the German version

I guess either my environment or yours has an issue as it seems you observed the same proble in #4516 too. I see German translations in the German version. Let's ask a third person to check it.

[m0ndra]

It's no one's fault but let me complain one thing:
I thought those two points above are to be implemented in one of the other issues as not explicitly stated in the acceptance crearia👁️ It's really hard to distinguish which changes belong to which issue: one can implement "all" changes visible in one of the design pages which is relavant to the current issue, but then a PR grows up at the end to include almost everything. This hits us hard in this issue series especially, because we do not have 6 different tables for 6 link categories, but all link categories share one table base (with a list of different links to display). So if you change for example a column name, it wll be changed in all categories. Messages like "URL/Email/Phonenumber was successfulyl replaced" and "Links were successfully marked as verified", "Verification was revoked for the links" are managed in one function and because of this my intuition was to fix it rather in #4469

Thanks for complaining ☺️ no really, it is super important. Also that's why I wrote that I am not sure if things will be implemented in other issues. With this Link Check GUI issue being so big i had a hard time with "what belongs to what" or "what can be done without touching others work", especially in the table design.

Let's do it like that: When most of the link check GUI issues are done, I'd love to do a design testing as a whole. And when things pop up then which might still be worth improving, I'll create a new issue with these fixes.

[seluianova]

design question:
@m0ndra do we need bulk actions for emails and phone numbers if they can't be verified?

[seluianova]

these icons are different from design (not sure if they have to be adjusted?)

Design:

CMS:

and this is not implemented:

or should I only check the items under Functional Criteria in the task description?
I am also a bit lost what should be implemented here 🙈

[seluianova]

I guess either my environment or yours has an issue as it seems you observed the same proble in #4516 too. I see German translations in the German version. Let's ask a third person to check it.

I also see those translations in English. others are in German. not sure why 🤷🏻‍♀️

[m0ndra]

design question: @m0ndra do we need bulk actions for emails and phone numbers if they can't be verified?

Ooohh, good catch, thanks! Actually no, we don't need it. And if we don't need bulk verifications, we also don't really need the checkboxes/multiselect. Since you can't do anything with selecting multiple mail adresses or phone numbers. I'll take that with me and think about it, and maybe open an additional issue for it since there is also another open question regarding the mail/phone table. So for now I'd keep it as it is implemented at the moment.

[m0ndra]

these icons are different from design (not sure if they have to be adjusted?)

Design:

CMS:

and this is not implemented:

or should I only check the items under Functional Criteria in the task description? I am also a bit lost what should be implemented here 🙈

@seluianova It is only necessary to check what is written under Functional Criteria. The details you mentioned are part of other issues, since we cut it in several small packages.

[seluianova]

tested Functional Criteria from the issue description, everything looks good to me 👍
I assume the problem with German translations is something local

[MizukiTemma]

design question: @m0ndra do we need bulk actions for emails and phone numbers if they can't be verified?

Ooohh, good catch, thanks! Actually no, we don't need it. And if we don't need bulk verifications, we also don't really need the checkboxes/multiselect. Since you can't do anything with selecting multiple mail adresses or phone numbers. I'll take that with me and think about it, and maybe open an additional issue for it since there is also another open question regarding the mail/phone table. So for now I'd keep it as it is implemented at the moment.

"Erneut prüfen" does not make sense at all for E-mails and phone numebrs, but "Als überprüft markiern" actually does a change: it sends all selected E-mails/phone numbers to the group of valid link group (although I think this is not the main use model 😅 just want to mention it).

[m0ndra]

but "Als überprüft markiern" actually does a change: it sends all selected E-mails/phone numbers to the group of valid link group

Yes. But then it will not be visible in the "All Emails"/"All Phone Numbers" table ever again (except if the user does a manual "Verifizierung entziehen" in the other table, which they will never do 😂 ).

(although I think this is not the main use model 😅 just want to mention it).

Exactly this! ☺️

-> I need to think this through.

[MizukiTemma]

@m0ndra @seluianova
Thank you for reviews and replies 🙏 I actually have no idea why translations don't work in you environment, but just rebased the branch. Could you pull the newest commits and see again?

[m0ndra]

@m0ndra @seluianova Thank you for reviews and replies 🙏 I actually have no idea why translations don't work in you environment, but just rebased the branch. Could you pull the newest commits and see again?

Yaaaaaaay I can see German texts! Don't know why but it works for me now.

[hannaseithe]

Thank you, for working on this. And making order out of the merge mess that is coming your way!

[hannaseithe]

I suggest also adding
´´´
self.form.fields["url"].widget.input_type = input_type
´´´

And to determine input_type based on the self.instance.type first. This will give us type="email" on the input field and so we can use the browsers own validation

[MizukiTemma]

@hannaseithe
Thank you for the review and suggestions.

Currently cross-type link replace is possible: for example, an emal URL can be changed to https://......... This behaviour will be blocked if sour suggestions are applied.

So, I would leave the PR as is.