Is it possible to allow the datepicker to only display certain months for user selection in orbeon form? e.g. only display Jan - Aug 2020? Or, is it possible to disable all dates out of those months?
You can exclude specific days (dates), so those days become greyed out in the date picker, and the value is also invalid if somehow one of those days gets selected. This is convenient to, say, exclude holidays. But it seems that supporting a start/end date is what you're looking for. This isn't yet implemented, see request for enhancement #4557.
So, for now, you can only enforce this through a formula (in Control Settings → Validations and Alerts). Users will still be able to select the date, i.e. it won't be greyed out in the date picker, but they will immediately see a message telling them that the date is invalid.
Related
There is a status in my JIRA instance called "Ready For Test" at which the tester would validate and close the jira. I need to know the amount of time the JIRA is in that particular status since it was moved from "In Progress" to "Ready to Test".
Is there a JQL query that can do it? I need this time field to be exported to Excel as well so that I can name and shame people and ask them to close the JIRAs as soon as they can.
I don't think it is possible on clean Jira installation. There are two plugins I know providing this kind of functionality:
Time in Status - self-explanatory
Enhancer Plugin (sorry, can't post more than two links) - adds a configurable time in status custom field, bt if I remember it correctly, it can display value only after you leave the status.
These are both paid, so that can be an issue.
Another option (if you're not using OnDemand) is the Script Runner Plugin. This plugin will allow you to create your own workflow postfunctions so you can store the "Ready to Test" transition date to one custom field and either calculate time and write it to another custom field when leaving that status or write a scripted field that will calculate and display current time since entering status. This solution is free (not counting your time to implement the functions).
Thanks #SilenyHobit for the idea. Here is what I've done:
First installed JIRA Suite Utilities plugin (its FREE)
Added a custom field called RFTDate (date type control)
Added a post function in RFT transition to update RFTDate with current datetime
Voila!!!
As an alternative, you can use Status Time Jira app. It provides reports on how much time passed in each status.
Once you enter your working calendar into the app, it takes your working schedule into account too. That is, "In Progress" time of an issue opened on Friday at 5 PM and closed on Monday at 9 AM, will be a few hours rather than 3 days. It has various other reports like assignee time, status entry dates, average/sum reports by any field(eg. average in progress time by project, average cycle time by issue creation month). And all these are available as gadgets on the dashboard too.
Here is the online demo link, you can see it in action and try.
As a free solution, you can try the limited version Status Time Free.
The dojox.widget.Calendar lets us scroll over the years easily. Can that be simulated/added to the DateTextBox widget?
I prefer the DateTextBox because of the validations and constraints it provides. Also, once opened, the Calendar widget (as in the livedocs site) cannot be closed till a date is selected. Whereas, the popup calendar in the DateTextBox does not have this problem.
The need is this: for a Date of Birth field, we cannot assume one random default year as, let's say, the potential users might be born any time between 1960 to 2000. So, the user might have to do multiple clicks (the older he is, the more number of clicks?!!). How can this usability problem be addressed? The Calendar widget helps in easy navigation. But the DateTextBox shows only 3 years at a time.
Can this be done with any CSS change? Any possible mix and match of components?
I am using v1.7.1
Thanks!
I have the same need. There is an open ticket (10002) but nothing has been done for years. I will try to get an answer on the mailing list.
Is there a way to create a SharePoint 2007 calendar that only allows users to input appointments in certain time slots? I would like the time slots to run Monday thru Friday from 8am - 10am, 10am - 12pm, 1pm - 3pm, 3pm - 5pm, and 5pm - 7pm. Only one person can sign up in a time slot at a time.
I do not want to have to enter every date from now till the end of time, which is the how this solution works: http://sharepointsolutions.blogspot.com/2009/02/give-blood-to-your-workflow.html
That is a great solution for the one-time Blood Drive type of time slotting but not exactly what I need.
I would either :
adapt the new form or create a custom one that will prevent people from adding a new event outside of your specified time slots and ensure that a specific time slot is not registered by someone else prior to save it. That will allow you to create a dedicated UI with relevant controls (eg : dropdown lists that have only the hours that you specified)
add an event handler on ItemUpdating that will ensure that there is no collision with another event and validate your business requirement regarding time slot. You can then transfer to an error page with a proper explanation message
Both solutions require custom development. I would be glad to hear if there is something out of the box that would fulfill this need.
I am trying to make a form field for a datetime property that allows the user to use a calendar for picking the date and also have something to choose the time graphically.
I've managed to get the jQuery UI DatePicker working for the date, but I have not way of presenting the time.
Is there a single component that does both?
Haven't seen for both. But for time, this one looks really good.
I'm working on a Rails application that's kind of like a blog. Users create Entries. I'm trying to work out how to handle time storage and display. I've read this writeup about Rails timezone support.
It's great but it doesn't cover what my app needs to do. It only looks at cases where you want to convert stored time to the current logged in user's time zone. In contrast, the effect I want is...
A user creates an entry in California at 10:00 a.m.
A couple years later he moves to New York and then at some point looks at his old entry. The "created" date should say "10:00 a.m." He doesn't care about time zones. He just wants to know what time of day he felt like it was when he wrote the entry.
If he then edits the Entry in New York the displayed "modified" date is, again, his subjective time of day when he made the edit. (Let's assume he went to "preferences" and changed his time zone setting when he moved.)
Also, for the sake of thoroughness, the app should be able to report the "real" absolute time when an Entry was created or updated.
(Note -- my imaginary user is a guy, but for women it should work roughly the same way.)
The way I'm thinking of implementing it is...
Have the attributes User#time_zone, Entry#created_at_utc, and Entry#updated_at_utc in addition to the standard created_at and updated_at.
The user selects their time zone from a menu when they sign up. (They can change it later if they want.)
The app uses User#time_zone to store created_at and updated_at in the user's subjective local time. If it's 10:00 a.m. for them, the app writes "10:00 a.m." to the DB.
The app also saves the current UTC time in the aforementioned _utc fields to deal with the last requirement above.
Is that a good way to do it? Is there a better way?
The two roads you can take are:
Store a timezone (UTC) in the user account as well as in every post - update the post's timezone along with the updated_at field whenever the user changes the post (if he or she has changed timezones).
Store the timezone only in the user account. When the user changes timezones, update every post that belongs to the user and add/subtract to the created_at/updated_at dates.
The first option seems like the cleanest option to take. For this you would only have to create a new method in your post record:
def locational_updated_at
updated_at + timezone.seconds
end
Where timezone is an integer containing the seconds since UTC.
If you can, you should avoid storing two different sets of timestamps, and you should avoid storing any non-UTC dates. Both of these things will lead to confusion. I'm not completely sure I understand what you're doing (though I like your idea of subjective time), but wouldn't it be enough to just attach a time zone to every post, and always use that zone to display the times? It would default to the time zone set in the author's account, so he could change it when he moved cross-country without affecting previous posts.
I think that's all you need--to attach a time zone to every post. Is that sufficient? Or am I missing some part of this?