In many reports there is the option to limit the report to a time span. I believe they call it a differential xxx (e.g. filter, dashboard, etc...). In the drop down there are three options: all time, 30 days, or 90 days. Is this customizable? Could it show the last 7 or 14 days? Could is show custom time spans. I would like to be to report on a sprint (we are practicing Agile Scrum). The behavior of developers is rhythmic and it would make the most sense to show reports for a sprint as this is the time span that determines the rhythm.
You'll find the answers to all your questions at http://docs.codehaus.org/display/SONAR/Differential+Views#DifferentialViews-DifferentialViewsSettings
Related
Are there any expiration period for this Power Automate - Approvals when the user taking more time to submit the decision?
I tried with some trial data but, need to get an idea from an experienced person.
Flows have a timeout period of 30 days.
You can refer to this documentation for more information.
https://learn.microsoft.com/en-us/power-automate/limits-and-config#duration-limits
If your approval is likely to run for more than 30 days, read this article.
https://learn.microsoft.com/en-us/power-automate/modern-approvals#create-long-running-approvals
I'm trying to run a task periodically every 12 hours, I'v used Work Manager and followed their documentation. The task is running periodically well as long as the user is actually using the app.
But if i close the app, or even just let my phone be idle for a while, it seems like the task stops working.
I searched for this problem on google, and came across posts such as this post, which i think explains the behaviour on my phone.
From my understanding, this problem is not related to work manager, but to all frameworks who will try to run background tasks?
Is there a way to still periodically run tasks on most devices or is WorkManager is still the way to go?
Thanks!
Please check this:
https://developer.android.com/topic/libraries/architecture/workmanager/how-to/debugging#use-alb-shell0dumpsys-jobscheduler
Required constraints: TIMING_DELAY CONNECTIVITY [0x90000000]
Satisfied constraints: DEVICE_NOT_DOZING BACKGROUND_NOT_RESTRICTED WITHIN_QUOTA [0x3400000]
Unsatisfied constraints: TIMING_DELAY CONNECTIVITY [0x90000000]
Minimum latency: +1h29m59s687ms
Run time: earliest=+38m29s834ms, latest=none, original latest=none
The periodic work is not exactly Periodic. You have different Constraints:
Explicit - you set them.
Implicit - set by the system related to Battery optimization. You should save the battery and also Internet usage.
When you have a "periodic work" you actually have an explicit constraint called:
TIMING_DELAY. But when the time is passed it does not mean that the work will start. It means that this constraint is satisfied and if and only all the other constraints are Satisfied - then the work will start.
And for example, you have your work with a "period" of 12 hours, but you wait an extra 4 hours for the other Constraints - you will have a period of 16 hours.
And after the work is finished - WorkManager will create a completely new job in the JobScheduler with TIMING_DELAY again - 12 hours. It will not account for the extra 4 hours. So you can't imagine something like:
I have 5 days so it means - 10 executions. It might be only 4 or 5 executions.
You can improve this by asking the user to exempt you from battery optimization:
https://developer.android.com/training/monitoring-device-state/doze-standby#support_for_other_use_cases
If you need to be really exact - you need to use AlarmManager, but mostly the idea of all of this is for the battery to be saved so it is not only about what the devs need, but also what the user needs.
How do I make the Jfxtras Agenda component treat the following two appointments as non-overlapping? Also, is there a way to increase the snap-to-grid granularity of the grid from 5 minutes to 30 minutes, to mimic Outlook? With the 5 minutes precision, it is very difficult to create back-to-back appointments, without making them overlap, or creating gaps between them.
Appointment 1
Start: 2pm
End: 5pm
Appointment 2
Start: 5pm
End: 9PM
I fixed the consecutive appointments rendering issue, the new snapshot should work ok. As for the rounding, I will add a CSS stylable property where this can be set later today.
I simply modified the appointment callback. To make it so that only 15 minute segments could be used to make appointments I used dateTimeRange.getStartLocalDateTime().minusMinutes(dateTimeRange.getStartLocalDateTime().getMinute()%15)
You can use this for the end time as well, and from then on you will only get appointments made with 15 min intervals. Just change the 15 to change the interval. The only potential downfall is that you could frustrate users if they shoot too low when dragging, but that could be solved as well with a simple if statement.
I've been trying to create notifications that happen on a weekly basis - for example, every monday at 8am.
I've tried to use a recurring toast for this - http://msdn.microsoft.com/en-us/library/windows/apps/hh465417.aspx - but realized that the recurrence parameters are more designed for a snooze functionality, with a maximum delay of 60 minutes, and a maximum repeat for 3 times.
Is there a suggested workaround for this?
Is there a best practice for such a use case?
Thanks!
You're right that the recurrence on scheduled toasts is designed for snooze. Unfortunately, the API doesn't provide a way to show the same toast multiple times on a fixed schedule.
You'll need to manually create a ScheduledToastNotification each time you want it to be shown. In your example, you might create and schedule out a toast a week for each Monday at 8 AM.
Is it possible to change the resolution time calculation to start not with the issue creation time, but rather with the time when an issue was transferred into a certain state?
The use case is as follows - We use a kanban-ish development method, where we create most issues/featues/stories in a backlog upfront; thus, this kills the usefulness of the resolution time gadget. In our case, the lead/resolution time should rather be calculated using the time where an issue has been pulled to the selected issues.
As this calculation is the basis for multiple gadgets, maybe it could be changed per gadget in order to avoid unforeseen issues with other gadgets?
There is a service level management tool SLAdiator (http://sladiator.com) which calculates resolution / reaction times based on the duration that ticket has spent in a certain status (or statuses). You can view these tickets online as well as get reports.