-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Date and time fields use browser-default selection widgets #4202
Conversation
We adopted this implementation: https://forum.djangoproject.com/t/possible-datetime-local-bug/9477/7 The utilities are in model_utils not utils/forms to keep model_utils from developing circular imports.
60c632a
to
9fa0397
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally this is a very welcome change. I've added a couple of questions inline though.
@@ -1016,6 +1017,7 @@ def publish_article(request, article_id): | |||
:param article_id: Article PK | |||
:return: contextualised django template | |||
""" | |||
from submission import forms as submission_forms |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does having this import in the head cause a circular import?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I believe so. There is another function in this file that has the same import.
else: | ||
modal = 'pubdate' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this unset on purpose? When the form is invalid generally we'd want to open the modal again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I unset it because there is a general redirect that resets the view and keeps the modal = 'pubdate'
from having any effect, and I didn't want to touch the redirect because I'd have to test all the other view branches:
@@ -524,3 +524,19 @@ def utility_clean_orcid(orcid): | |||
|
|||
# ORCID is None. | |||
return orcid | |||
|
|||
|
|||
class PubDateForm(forms.ModelForm): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great.
</div> | ||
</div> | ||
</div> | ||
{{ pub_date_form }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, that is wild. Firefox clears it in my inspector pane (after parsing the HTML) but I can see it when I inspect the source. Is this a Django default feature, or something we have configured? In any case, I've added the foundation filter.
This closes #4095 as documented in that issue. Also closes #4205
The pub date selector was the only date+time combination:
In adding the form for selecting a pub date, I fixed up the confirmation message a bit so that it is crystal clear even with a timezone difference:
To make the datetime picker work, I used a custom model field as documented on the Django forum as discussed.
But as a side effect, an error is thrown when saving the model in the admin. (Change the Article admin back to
admin.ModelAdmin
to see the error.) To handle this I created an override to use the same widget in the admin. It is a bit ugly:If we don't like this we can simply drop the ModelField and use the custom FormField or widget independently.