[PATCH] Generalized date fields for use elsewhere

[terje]

• Configurable request match (for using datepicker elsewhere)
• Instead of attaching a separate datepicker to explicit fields, attach to class=datepicker + use a stream filter to set the class attribute of input elements
• (Limited) support for using datepicker for milestone due/completed (default=off)

Not really tested, Works For Me..

[terje]

Generalized a litte, plus new features

[terje]

Fixed request match to handle webadmin, and dont assign anything to data.ids

[anonymous]

Will

 attr('class', 'datepick') 

cause problems if the sites template uses a class already? Is there a way we can append the class?

[Robert Corsaro]

(In [7192]) generalize datepicker

Now kinda works with milestones. Uses a class name instead for future enhancements. fixes #6246. thanks terje!

[terje]

Replying to anonymous:

Will

 attr('class', 'datepick') 

cause problems if the sites template uses a class already? Is there a way we can append the class?

Yes I think it will cause trouble. Not sure what is the best solution. Maybe leave the class alone if it is set already by default? (override option)

Ultimately I think we can solve it by attaching to IDs _and_ classes (so we'd be able to have H:M:S for milestone fields etc), akin to:

[datefield]
class=ticket_due,milestone_due,milestone_comp
id=special_field1,special2
ticket_due.format = ymd
milestone_comp.format = ymdhis

And use this config to create a list of .classes and #fields to attach datepicker to. This is actually what I do in production, but it's very messy.

On a sidenote, I notice this doc= change in [7192] "(..) you must use MM/DD/YYYY for the date format. Set format to mdy and separator to / (..)".

This depends on locale - I use DD-MM-YYYY for milestones.