Would also fix #8354

Can we reuse the import handler here so that other features (like automatically generating timestamps etc) are also working as expected?

Good idea, but the import handler does not check for duplicates. That only happens in the New Entry dialog

I guess it make sense to extract the duplication check also to the import handler. Then one would get also a duplication warning if one say uses copy&paste of an id to create an entry. That's a nice enhancement in my opinion. (The only situation where you don't need this check is after the import dialog, which already handles this.)

Related: #8406

When an entry is pasted or imported by id and already exists, the duplicate resolver dialogs opens. And also the keys are generated
Works also for pasting DOI.
@ThiloteE you can test here (when the deployment green)
https://builds.jabref.org/pull/8361/merge/

Found a bug:

1. have entry1 in libraryA
2. have entry2 to libraryB
3. Both have similar entry data, except citationkey.
4. Copy and paste entry2 to libraryA.
5. The entry merge dialogue will emerge
6. Click on "Do not import entry" OR click on the X in the top right corner of the entry merge dialogue (to close the dialogue).

• The entry2 WILL get imported.
• (This entry2 will get assigned a new citation key that follows my citation key patterns I declared in my preferences, It will be two different citationkeys, because duplicate prevention adds a letter at the end.)

Expected outcome:

This entry2 SHOULD NOT get imported.

Expected outcome: The entry should NOT get imported.

Bug 2:

EDIT: SORRY, I noticed ONE CAN DISABLE overwriting the citation key by disabling the preference in options>preferenes>import and export>generate a new key for imported entries (overwriting their default). The other part of this bug here still applies (what you can see in the picture), but should not be too concerning. I might open a new issue for this. I think it should not be relevant enough to prevent merging this pull request, I guess?

0.1 Have "overwrite existing keys" in Keygen preferences DISABLED.

1. Have a key pattern in keygenerator
2. Have entry3 with DOI in LibraryC
3. Copy DOI.
4. Paste DOI in LibraryC
5. Entry Editor emerges
   
   5. Choose "import and keep old entry"

What happens:

- Entry3 is kept (good!)
- A new entry4 is imported, but old citationkey (of entry4) is overwritten by citationkey pattern that was specified under preferences.

• Old and new entry are flipped.

Expected Outcome:

- Entry4 is imported with original citationkey from internet.
- Citationkey of entry4 should NOT be overwritten.

• Old entry should be on the left, but is on the right. New entry should be on the right, but is on the left.

Sorry. 😅

Solving the first bug might also solve #5858? Just maybe?

Thanks for testing, will check this again wth the right/left thing

@ThiloteE I fixed the cancellation and the order in the dialog. Can you please test again?
https://builds.jabref.org/pull/8361/merge/

Looking quite good! Solved 2 issues. 1 new issue pops up 😂 Hopefully the last one.

Bug3:

1. Have options>preferenes>import and export>generate a new key for imported entries (overwriting their default) enabled.
2. Have a customized key-pattern for the citation-key generator set in preferences.
3. Have this preference set under citation-key generator preferences:
   
4. Import entry by ID into library5 OR paste entry5 by ID into library5. Let's call this one entry5.
5. Import entry by ID into library5 OR paste entry5 by ID into library5 AGAIN. Let's call this one entry5².
   • Duplicate Merge Editor will emerge. So far so good.
6. Click keep merged entry only

Result:

• entry5² will get assigned citationkey-according-to-my-pattern+a

Expected result:

• entry5² will get assigned citationkey-according-to-my-pattern

Additional info:

This becomes really weird when entry5 and entry5² are not exactly identical. E.g.

• entry5: date = {2016}
• entry5²: date = {2016-10-02}

My key pattern includes the date into the citation-key. Therefore,

key before merge: 2016
key after merge: 2016-10-02a, EVEN THOUGH 2016-10-02 would be unique in my library.

All the other buttons work and I have not noticed any other bugs so far.

I reverted the changes to the citation key method as this would break more tests and is an unusual edge case.

I can confirm it fixes JabRef#553.

It does NOT fix #8406. See https://www.loom.com/share/0c29cb50e91c431488a54c3c5266379d, in case of huge diffs

@Article{Kopp2015,
  author    = {Kopp, Oliver and Martin, Daniel and Wutke, Daniel and Leyman, Frank},
  journal   = {Enterprise Modelling and Information Systems Architectures},
  title     = {The Difference Between Graph-Based and Block-Structured Business Process Modelling Languages},
  year      = {2015},
  pages     = {No 1 (2009)},
  volume    = {Vol 4},
  doi       = {10.18417/EMISA.4.1.1},
  language  = {en},
  publisher = {Gesellschaft für Informatik e.V. (The German Informatics Society)},
}

@Article{Kopp2015,
  author    = {Kopp},
  year = {2015},
}

--> Future work