Rework deprecated fields in Biblatex mode

[stefan-kolb]

Are they still neeeded?

[lenhard]

What is the status here? Could you maybe explain a little bit what this issue is about and what the problem is? I do not really get it from the current description.

[stefan-kolb]

I'm not really sure why we still need this or how we should proceed with this feature.

[koppor]

• Remove Optional fields and Optional fields 2 from the logic. It should be only used in the UI.

[stefan-kolb]

Remove Optional fields and Optional fields 2 from the logic. It should be only used in the UI.

This is inside another issue @koppor
We can probably just keep the deprecated fields inside a separate tab to show the user that they have been deprecated or what about this solution?:

• Remove the tab and display them inside the other tab as for all other not required or optional fields
• Provide an integrity check to show the user that they need to be migrated
• Maybe even supply and automated migration

[mlep]

To your solution, I would add:

• in the UI, identify the depreciated fields with a specific background color or a symbol

[lenhard]

I think there is no point in moving this issue to another milestone again.

[wujastyk]

JabRef 4.0.0-dev--snapshot--2017-07-13--master--504646403
Linux 4.8.0-58-generic amd64
Java 1.8.0_131

---

The "deprecated fields" tab is is still a troublesome issue.

The problem: the tab takes up a relatively large amount of precious screen space, and - for me at least - offers zero purpose.

Example: at the moment, "book" has "archiveprefix" as the single entry in "deprecated fields" (see picture below). Why? Where is this coming from? My biblatex entry does not include an "archiveprefix" field. Looking at "customize entry types," "archiveprefix" is not a field used in book-type entries at all, in any category.

Why is JabRef rapping my knuckles about "archiveprefix", when it doesn't appear anywhere, isn't part of the document definition?

This "deprecated fields" screen should go, and soon. Some of the solutions above are more elegant and efficient. I like mlep's proposal of Dec 8 2016, about flagging deprecated fields with a colour.

Whether that's the answer or not, the "deprecated fields" tab in its present incarnation is without function (that I can see), confusing, and space-consuming.

Best,
Dominik

[lenhard]

@wujastyk Thanks for the input! We still want to rework the field structure in the entry editor. We just decided to exclude it from 4.0, because we rather want to focus on a (relatively) bug-free entry editor. The restructuring will come afterwards.

[wujastyk]

understood! Thank you for your work! ​

…

On 14 July 2017 at 13:56, Jörg Lenhard ***@***.***> wrote: @wujastyk <https://github.com/wujastyk> Thanks for the input! We still want to rework the field structure in the entry editor. We just decided to exclude it from 4.0, because we rather want to focus on a (relatively) bug-free entry editor. The restructuring will come afterwards. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#730 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAuhhlHkzwQabBx64yGjcuWHJaPxXtj5ks5sN1dggaJpZM4HORhC> .

[lenhard]

We'll now take the discussion about restructuring the entry editor over to #2790 There's no reason to discuss each tab separately in a different issue. Instead, we should come up with a good solution of tabs and fields for the complete entry editor.

Please add further discussion of this issue to #2790