Fix duplicate external file type issue when change language and other corresponding issue of external file type preferences

[papatekken]

In Preferences->External file types,

1. fixes preferences: external file types duplicates #10271, which is about duplicate issue when changing the langauge
2. EditExternalFileTypeEntryDialog Cancel button close the dialog and wont take further action
3. Missing value in EditExternalFileTypeEntryDialog will block the closing dialog action when OK button clicked
4. New External File Type cannot saved if the new file extension exists already

*Notify message was added but no translation done.

Mandatory checks

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• [x ] Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[Siedlerchr]

There are failing tests
some are for l10n
see https://devdocs.jabref.org/code-howtos/localization.html

[papatekken]

thanks for your feedback, I will follow up soon later this week.

[koppor]

1. fixed duplicate issue when change langauge #10127

This issue is JabRef/JabRefOnline#2136 - I think, you linked the wrong number. Can you check?

[koppor]

1. fixed duplicate issue when change langauge #10127

This issue is JabRef/JabRefOnline#2136 - I think, you linked the wrong number. Can you check?

Ah, it is #10271 (not #10127 - numbers swapped) - I fixed it in the PR descriptoin, too.

[koppor]

@papatekken Would it be possible to add tests to ExternalFileTypesTabViewModel? With your changes, the ViewModel gets more complicated and should be testet.. - I know, this could be hard, but a good learning of mock frameworks.

[koppor]

OpenRewrite complains because of style - see the failing "Tests / Code style check" at https://github.com/JabRef/jabref/actions/runs/6593745520/job/17916664973?pr=10496.

Please run ./gradlew rewriteRun to rewrite your code - and check if the resulting code is "better"

[papatekken]

@koppor sorry for mix up the number.

I followed the documentation and tried checkStyle plugin locally but all passed.

Anyway I will try to run rewriteRun and see if that can help. I will add the test as you suggested too. Thanks for your comments.

[koppor]

I followed the documentation and tried checkStyle plugin locally but all passed.

No worries. -- We have some more steps in there. See

jabref/.github/workflows/tests.yml

Line 63 in 1fb17d3

- name: Run OpenRewrite

We did not mention that in the documentation. I am trying to get a bot commenting on the PR to guide more. See #10532.

Updating the documentation is future work :).

[koppor]

Time is currently shor tin our side. May I ask for a test of ExternalFileTypesTabViewModel (at least of the changes you did)?

[papatekken]

Time is currently shor tin our side. May I ask for a test of ExternalFileTypesTabViewModel (at least of the changes you did)?

Sure, I planned to do so, now I target to complete test before Monday hope this is ok, thanks

[koppor]

1. Known file type added. I am not able to submit (which is OK). However, there should be an error indicator shown at the text field causing the issue. I think, this is difficult to implement, thus, OK for me.
2. If I edit an entry and re-use an existing mime-type (2.g., image/vnd.djvu). I can still submit. Mime types are globally unique. Thus, would it be possible to add a check for that?
3. If I edit an entry - and use an existing name (e.g., CHM), I can still submit. Thus, would it be possible to add a check for that?

Otherwise: Looks good to me!

[koppor]

Where do I see these messages? I did not see them here? @Siedlerchr Do we need to change something in the overall code?

[papatekken]

@koppor
I following the code from GroupDialogViewModel.java.
In that class there is a function validationHandler. However even with that function I still cannot see the error message, so I didnt include that.

[papatekken]

koppor

No problem, I will add unique validation for name and mime-type as well. For error message, I am not sure at the moment.

[koppor]

Tried it out. Works good. I will ask @Siedlerchr about the validation messages.

[Siedlerchr]

I was so free to add the missing visualizaion implemention.
Basically you missed the initVisualization for the property/control. This also required me to combine the two validators forreach field, e.g. same name and isNotBlank

[papatekken]

I was so free to add the missing visualizaion implemention. Basically you missed the initVisualization for the property/control. This also required me to combine the two validators forreach field, e.g. same name and isNotBlank

thanks @Siedlerchr , I get it now, and it's good to learn something new