Please use space rather than tabs :)

Looks like we can format it and put indentation here.

Meaningful variable name here please :smile:

Is it absolutely necessary to use None?

None has been used here ^^^ before, that's the only reason I've used it, too

is the console log required?

only for the review to show that the class that hides the element got removed

There is something odd here, the value of the date field is filled in the settings page or in the ticket that gets this field?

From my local testing, it asks for a value (though doesn't enforce it) in the settings page, while I would expect that the value (thus the calendar widget) shows up when I try to set it in the issue page, no?

It looks like it was rebase but I don't think my previous comment was addressed, was it? (I may be missing it)

No, I've worked on the /pull-request/ready stuff as that had priority

Test passed, please review.
I've removed the date input field from the settings page and moved it to the issues metadata tab.

I'm confused about these two lines

I'm confused about these two lines

They make sure that at least an empty string gets returned, otherwise you'll get failures in pagure/lib/__init__.py around line 4773 when the number of data entries doesn't match the number of types entries.

We could drop the title, class and if the key_type is not a list, is there a reason to do the join(', ') ?

Shouldn't we use elif instead of if/else/if/else ?

I'd drop the title if this is hidden, same for the css class.
The value could also likely be simplified to {% field.data or "" %}

I've changed that to "{{ field.data or '' }}". The css classes needs to stay, otherwise the input filed has the wrong size when you switch from one key_type to 'list'

I've dropped the 'Date' stuff completely, not required here

title and class need to stay, otherwise you won't get the input field mouseover hint and the wrong field size when you create a text field, press update and then decide to change that to 'list'

Looks all good and jenkins is happy to, the only thing I see is: The format when adding the date is MM/DD/YYYY while it's shown as yyyy-dd-mm ? Could we change the input field? (Even if only to YYYY/MM/DD)

If not, I'll merge as is :)

Unfortunately not that easily. Most browsers show a calender picker widget where this doesn't matter. Your browser doesn't seem to support that and what text is shown depends on the browser and language settings.

Your browser doesn't seem to support that and what text is shown depends on the browser and language settings.

It does show the calendar widget but the place holder is US format unlike what we display.

If it's related to the browser and language settings then I'm fine. Let's get this in :)

Actually, is this change still needed?

I've adjusted this PR a little bit (tests were failing) and I squashed all commits into one.
I'm running the tests locally and if they pass, I'll merge :)

Thanks @karsten for your work on this! :)