I used to be able to edit the target date just by moving the edge of the card on delivery plans. But Today, every story I create has the target date associated to the iteration and not the day it should finish.
Is this any type of configuration I'm missing os is it a bug from devops?
Best,
Ricardo
I tried to find a configuration that addresses this issue but I couldn't find anything
Check this practics: https://learn.microsoft.com/en-us/azure/devops/boards/plans/review-team-plans?view=azure-devops#best-practices-for-using-a-delivery-plan
Use Start Date and Iteration to specify the time frame for a work
item. Or, use Start Date and Target Date. However, don't specify both
Iteration and Target Date for a work item. Target Date will always
override the Iteration end date on the plan.
So.. you may set Target Date in your plan manually then the delivery plan will use Target Date as a planning point.
On the screenshot, the first work item uses start and target dates, and the second one start date and iteration:
Related
I currently have a report with the ability to select a start and end date. I was curious if you could make have both preset and the option for a custom selection
Selection:
Current Week, or
Previous Week, or
Custom Date Range.
Thanks,
Take a look at cascading parameters.
The link above seems to focus more on getting your cascading parameter values from a query, but you probably don't want that for a date - as far as I am aware, setting Available Values for a date parameter limits you to a dropdown list of dates, instead of the calendar which is generally easier to use. It is still a good background on how cascading parameters work though.
To do this with expressions for the default start/end date, you would basically want the first parameter to be a choice between "Current Week", "Previous Week", and "Custom Date Range". You would display those labels to the user, but the values can be whatever you want - for my test I just used 1, 2, and 3.
Then, you would set up 2 more parameters, one for the start date and one for the end date. Make sure the data type is Date. You will want to set up default values for these based on the value of the first parameter. I would do this with an expression such as the expression below for the start date. You also may need to modify this a bit depending on how you define the week - is the "Current Week" just the previous 7 days, or is it the latest Monday through today, or something else, etc.
=Switch(
Parameters!FirstParam.Value = 1, DateAdd("d", -7, Today()),
Parameters!FirstParam.Value = 2, DateAdd("d", -14, Today())
)
In this case, you don't even need to account for the 3rd option, because if the user wants a custom date range then you do not want the start and end date to fill in with any default values. You would need a similar expression for the default end date as well.
Since you want the user to be able to enter a custom range as well if they were to select the third option, you do not want to fill in the Available Values for the start/end date parameters, as the user would then not be able to select any date (at least as far as I am aware - if there is a workaround to that, I would love to see it, as that would be something I would like to use myself).
A possible downside to this approach is that if the user begins by selecting Current Week and then changes their mind to Previous Week, the start/end dates will not change to the Previous Week. You can read more about why this happens here, but essentially: since the values that are already filled in after selecting Current Week are still valid (they are dates, which is the only criteria for those parameters since no available values are set up), they will not refresh after changing the selection. The fix for this is to define the Available Values, but as mentioned above, this will then stop the user from entering a custom date range.
Let's say I have a date dimension and from my business requirements I know that the most granular I would need to go is to examine the specific day of the month that an event occurred.
The data I am given provides me with the exact time that an event occurred (YYYY-MM-DD HH:MM:SS). I have two opitons:
Before loading the data into the date dimension, slice the HH:MM:SS from the date.
Create the time attributes in my date dimension and insert the full date time.
The way I see it, I should go with the option 1. This would remove redundant data and save some space. However, if I go with option 2, should the business requirements ever change or if my manager suddenly wants to be more granular I wouldn't need to modify my original design. Which option is more commonly used? Are there more options that I did not consider?
Update - follow up question
I receive new data every month. If I used a pre built date dimension with all the dates would I then need to run my script every month to populate the table with new dates of that month or would I have a continuous process where by every day insert into the table one row, which would be that date?
I would agree with you and avoid option 2. A standard date dimension table is at the individual date level. If you did need to analyse by time of day, you could create an additional time of day dimension at the level of a second in a single day, and link to that from your fact table.
Your date dimension should be created by script automatically, rather than from the dates that events occurred. This allows you to analyse across a range of events from other facts, and on dates where no events occur, using a standard, prebuilt dimension.
I would also include the full date/time stamp as a column in the fact table, along with the 'DateKey' to the dimension table. This would allow you some visibility/analysis of the timestamp, you would not lose the data, and would still allow you to analyse by the date dimension.
Update - follow up question
Your pre-built date dimension (the standard way of doing it) would usually contain some dates in the future. There's no reason not to, for example, include another 5 years of dates in the table. But if you'd like it to gradually grow over time, you could have a script that is run once a day, once a month, or once a year to add new dates. Its totally up to you! There are many example scripts for building date dimensions- just google date dimension script. They exist for the language of your choice, e.g. SQL, C#, Power Query, etc.
Context: I am using Microsoft Dynamics (CRM) and Eloqua to send email campaigns. I have a date field in CRM that I want to check against in Eloqua for a specific campaign. This campaign needs to check to see if the date field is <= today's date + 90 days. I am using the campaign UI in Eloqua, not doing anything programmatically at this point.
I have tried using the Compare Custom Object Fields decision in Eloqua by finding the date field, setting the comparator to dynamically on or before, and I want to make the compared value Today + 90 days. I'm not sure how to accomplish this in this type of Decision object because the only options I have to compare the date field to are Yesterday, Today, or Tomorrow. See image below:
I have also tried to use the Compare Date Decision object, but there is no dynamic comparison, just hard-coded date options.
The last thing I tried was a Wait step, but that only waits a hard-coded number of days rather than checking dynamically.
Has anyone run into this issue or know of a solution to this problem?
We were able to find an Eloqua Date App to download that adds a Date Decision step to the program builder which allowed us more flexibility with comparing dates in a custom range.
I would like to know how to pre-fill the Scheduling Start and End Date in the metadata/properties of each item edited or created in a SharePoint list.
Scheduling Start Date: Today's date.
Scheduling Start Date: Today's date + one year.
Reason for ask: I configured the list items to expire and move into "draft" status when they hit their specified Scheduling End date, therefore un-publishing the item from external view.
Problem: Users/contributors are creating these items and are not entering enough time for it expire. What I'd like to do is automatically pre-fill the scheduling end dates for one year out from today's date when an item is edited or created.
Background info: I've enabled scheduling of items in a list (via "Enabling scheduling of items in this list" option in "Manage item scheduling" in Library Settings). I currently have a workflow and versioning enabled so that the admins check the content before it's view-able externally.
Your thoughts are appreciated.
This is pretty easy using Calculated Field Formulas in the default value fields of your two columns. Here and here are discussions on the basics of setting a default value for a date field, but it's pretty straightforward.
For Scheduling Start Date, set the default value to Today's Date. For Scheduling End Date, use the calculated value of =DATE(YEAR(Today)+1,MONTH(Today),DAY(Today)) for the default value.
I am having trouble grouping certain results in a work in progress report that arranges by start date, I have grouped using fixed values before but because the dates keep moving I am unsure what to do.
The start date is WIP_Schedule.Start_Date
the groups I am trying to create are:
[Group1] Overdue = the current date has passed the start date.
[Group2] (Yet to be named) = the current date 2 week period prior to the start date
[Group3] To Do = the current date after the two week period prior to the start date.
I am after a works instruction on how to achieve this.
I know this isn't a lot of information, if you require any more please ask.
Thanks,
Daniel
This is a pretty straightforward requirement, so you should be able to figure it out by searching the web. However, I'll give you part of the answer and hopefully you can figure it out.
Start by creating a formula to figure out the status of the date.
If {WIP_Schedule.Start_Date} > current date then "Overdue"
Else......
Then you can group based on that formula. All you have to do is figure out the rest of the formula.