I'm trying to have a single (if possible) event or multiple events linked to each other with multiple dates and hours. So that the user can have a delete all option related to this event(s).
Original hours in postman body:
"start": {
"dateTime": "2022-09-01T09:00:00+02:00",
"timeZone": "Europe/Brussels"
},
"end": {
"dateTime": "2022-09-01T17:00:00+02:00",
"timeZone": "Europe/Brussels"
},
"Recurring" hours:
2022 09 02 10:00:00 → 2022 09 02 15:00:00
2022 09 03 10:00:00 → 2022 09 03 19:00:00
I tried to use the recurrence with RDATE;VALUE=DATE:20220902T100000/20220902T150000,20220903T100000/20220903T190000, tried to use some combination of UNTILL and the previous value but this will always take the original hours.
Then I found the related-to documentation but I'm unable to link the first event to the rest as the documentation uses an email and not an id which is what I would expect.
The following is an example of this property:
RELATED-TO:jsmith.part7.19960817T083000.xyzMail#example.com
RELATED-TO:19960401-080045-4000F192713-0052#example.com
Is there a way to have a single event with multiple dates and multiple hours or are multiple events the only way?
How would I begin "linking" them together so the user can have the delete all option?
Ok so I have this moment object I'm looking at in Developer Tools:
amoment: Moment
_a: (7) [2017, 4, 21, 20, 15, 0, 0]
_d: Sun May 21 2017 15:15:00 GMT-0500 (Central Daylight Time) {}
_f: "MM/DD/YYYY h:mm A"
_i: "5/21/2017 8:15:00 PM"
_isAMomentObject: true
_isUTC: true
_isValid: true
_locale: Locale {_calendar: {…}, _longDateFormat: {…}, _invalidDate: "Invalid date", ordinal: ƒ, _dayOfMonthOrdinalParse: /\d{1,2}(th|st|nd|rd)/, …}
_offset: -180
_pf: {empty: false, unusedTokens: Array(0), unusedInput: Array(1), overflow: -1, charsLeftOver: 3, …}
_strict: false
_z: Zone {name: "America/Halifax", abbrs: Array(229), untils: Array(229), offsets: Array(229), population: 390000}
__proto__: Object
As you can see, the text representation is 5/21/2017 8:15:00 pm. This is the correct time in UTC and I notice "_isUTC" is "true".
The _d property shows that datetime in CDT, where I am now.
The _z property shows a Zone object set to "America/Halifax"--this is dynamically set elsewhere, but also correct.
I would like to return a moment reading "5/21/2017 5:15:00 pm" because that's what that datetime is in "America/Halifax."
There are so many moment.js functions I haven't found the right way to do this.
All of the fields that begin with underscores (_) are meant to be internal to Moment. You should not be using them at all. More on this here, and here.
To output a string in a particular format from a moment object, use the format function. For example:
yourMomentObject.format("M/D/YYYY h:mm:ss a") //=> "5/21/2017 5:17:00 pm"
I ended up doing new Date(amoment.format('YYYY-MM-DDTHH:mm:ss+00:00')); which worked for my purposes. The zone kept wanting to render the date in that zone, so I just had to omit it.
we are trying to implement timeout for a participant step. But it doesn't seem to be working. When i configure the timeout as immediate, we are able to see the timeout behavior , but when we select the actual time like 1 hr. It is not timing out after the specified time interval. Is there any other configuration that we have to do to achieve this?
This is because of a bug in com.adobe.granite.workflow.core.job.WorkflowJobUtils as I see. When I set timeout for a Participant step to 1h there is the message in log
03.10.2018 16:26:10.681 *DEBUG* [0:0:0:0:0:0:0:1 [1538573170619] POST /etc/workflow/instances HTTP/1.1] com.adobe.granite.workflow.core.job.WorkflowJobUtils calling createTimeoutJob for workitem /etc/workflow/instances/server0/2018-10-03/test-model_98/workItems/node1_etc_workflow_instances_server0_2018-10-03_test-model_98
03.10.2018 16:26:10.681 *DEBUG* [0:0:0:0:0:0:0:1 [1538573170619] POST /etc/workflow/instances HTTP/1.1] com.adobe.granite.workflow.core.job.WorkflowJobUtils create timeout event {com.adobe.granite.workflow.console.timeout.job=com.adobe.granite.workflow.job.TimeoutJob#989455c, event.timed.date=Wed Nov 14 08:26:10 MSK 2018, event.timed.id=/etc/workflow/instances/server0/2018-10-03/test-model_98/workItems/node1_etc_workflow_instances_server0_2018-10-03_test-model_98_1538573170632}
"event.timed.date=Wed Nov 14 08:26:10 MSK 2018", when the step is assigned to a participant on October 3 at 4 pm. You can add the logger and check from your side, I'm using AEM 6.3. This is the step configuration:
code from WorkflowJobUtils:
Long timeout = (Long)item.getNode().getMetaDataMap().get("timeoutMillis", Long.class);
Date date = calculateDate(timeout.longValue(), addOffset);
props.put("event.timed.date", date);
LOGGER.debug("create timeout event {} ", props);
jobBuilder.properties(props);
List<String> errors = new ArrayList();
ScheduledJobInfo result = jobBuilder.schedule().at(adjustDate(date)).add(errors);
private static Date calculateDate(long seconds, boolean addOffset) {
Calendar cal = Calendar.getInstance();
long millies = seconds * 1000L;
if (addOffset) {
millies += cal.getTimeInMillis();
}
cal.setTimeInMillis(millies);
return cal.getTime();
}
you see in the calculateDate method they expect seconds, but actually for the "1h" option milliseconds are set, 3 600 000. So they multiply it to 1 000 and get 3 600 000 000 millisecond or 3 600 000 seconds, 1 000 hours or 41.6 days.
you can add a new option for the Timeout dropdown here /libs/cq/workflow/components/model/step/tab_common/items/timeout/items/timeout/options as a workaround.
After I added a new option with value "1" there the timeout handler was called:
03.10.2018 16:38:54.200 *DEBUG* [0:0:0:0:0:0:0:1 [1538573934182] POST /etc/workflow/instances HTTP/1.1] com.adobe.granite.workflow.core.job.WorkflowJobUtils calling createTimeoutJob for workitem /etc/workflow/instances/server0/2018-10-03/test-model_99/workItems/node1_etc_workflow_instances_server0_2018-10-03_test-model_99
03.10.2018 16:38:54.201 *DEBUG* [0:0:0:0:0:0:0:1 [1538573934182] POST /etc/workflow/instances HTTP/1.1] com.adobe.granite.workflow.core.job.WorkflowJobUtils create timeout event {com.adobe.granite.workflow.console.timeout.job=com.adobe.granite.workflow.job.TimeoutJob#267dc5f3, event.timed.date=Wed Oct 03 16:38:55 MSK 2018, event.timed.id=/etc/workflow/instances/server0/2018-10-03/test-model_99/workItems/node1_etc_workflow_instances_server0_2018-10-03_test-model_99_1538573934194}
03.10.2018 16:38:59.335 *INFO* [sling-oak-observation-212] org.apache.sling.event.impl.jobs.queues.JobQueueImpl.Granite Workflow Timeout Queue Starting job queue Granite Workflow Timeout Queue
03.10.2018 16:38:59.336 *INFO* [sling-oak-observation-212] org.apache.sling.event Service [QueueMBean for queue Granite Workflow Timeout Queue,14915, [org.apache.sling.event.jobs.jmx.StatisticsMBean]] ServiceEvent REGISTERED
03.10.2018 16:38:59.435 *DEBUG* [sling-threadpool-7e90cbd1-c78f-4aff-add9-eba2c792e8fe-(apache-sling-job-thread-pool)-22-Granite Workflow Timeout Queue(com/adobe/granite/workflow/timeout/job)] com.adobe.granite.workflow.core.job.TimeoutHandler process timeout job for event JobImpl [properties=org.apache.sling.api.wrappers.ValueMapDecorator#136322bc : {slingevent:application=fa67a921-cc59-4097-953a-a6e69ff5b718, jcr:created=java.util.GregorianCalendar[time=1538573939311,areFieldsSet=true,areAllFieldsSet=true,lenient=false,zone=sun.util.calendar.ZoneInfo[id="GMT+03:00",offset=10800000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2018,MONTH=9,WEEK_OF_YEAR=40,WEEK_OF_MONTH=1,DAY_OF_MONTH=3,DAY_OF_YEAR=276,DAY_OF_WEEK=4,DAY_OF_WEEK_IN_MONTH=1,AM_PM=1,HOUR=4,HOUR_OF_DAY=16,MINUTE=38,SECOND=59,MILLISECOND=311,ZONE_OFFSET=10800000,DST_OFFSET=0], event.timed.date=Wed Oct 03 16:38:55 MSK 2018, slingevent:created=java.util.GregorianCalendar[time=1538573939203,areFieldsSet=true,areAllFieldsSet=true,lenient=false,zone=sun.util.calendar.ZoneInfo[id="GMT+03:00",offset=10800000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2018,MONTH=9,WEEK_OF_YEAR=40,WEEK_OF_MONTH=1,DAY_OF_MONTH=3,DAY_OF_YEAR=276,DAY_OF_WEEK=4,DAY_OF_WEEK_IN_MONTH=1,AM_PM=1,HOUR=4,HOUR_OF_DAY=16,MINUTE=38,SECOND=59,MILLISECOND=203,ZONE_OFFSET=10800000,DST_OFFSET=0], event.job.queuename=Granite Workflow Timeout Queue, event.job.queued.time=java.util.GregorianCalendar[time=1538573939203,areFieldsSet=true,areAllFieldsSet=true,lenient=false,zone=sun.util.calendar.ZoneInfo[id="GMT+03:00",offset=10800000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2018,MONTH=9,WEEK_OF_YEAR=40,WEEK_OF_MONTH=1,DAY_OF_MONTH=3,DAY_OF_YEAR=276,DAY_OF_WEEK=4,DAY_OF_WEEK_IN_MONTH=1,AM_PM=1,HOUR=4,HOUR_OF_DAY=16,MINUTE=38,SECOND=59,MILLISECOND=203,ZONE_OFFSET=10800000,DST_OFFSET=0], jcr:createdBy=sling-event, sling:resourceType=slingevent:Job, slingevent:eventId=2018/10/3/16/38/fa67a921-cc59-4097-953a-a6e69ff5b718_92, event.timed.id=/etc/workflow/instances/server0/2018-10-03/test-model_99/workItems/node1_etc_workflow_instances_server0_2018-10-03_test-model_99_1538573934194, event.job.application=fa67a921-cc59-4097-953a-a6e69ff5b718, event.job.retries=10, com.adobe.granite.workflow.console.timeout.job=com.adobe.granite.workflow.job.TimeoutJob#29a9a2f7, event.job.started.time=java.util.GregorianCalendar[time=1538573939376,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/Minsk",offset=10800000,dstSavings=0,useDaylight=false,transitions=69,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2018,MONTH=9,WEEK_OF_YEAR=40,WEEK_OF_MONTH=1,DAY_OF_MONTH=3,DAY_OF_YEAR=276,DAY_OF_WEEK=4,DAY_OF_WEEK_IN_MONTH=1,AM_PM=1,HOUR=4,HOUR_OF_DAY=16,MINUTE=38,SECOND=59,MILLISECOND=376,ZONE_OFFSET=10800000,DST_OFFSET=0], jcr:primaryType=slingevent:Job, event.job.retrycount=0, :sling:jobs:asynchandler=org.apache.sling.event.impl.jobs.JobConsumerManager$JobConsumerWrapper$1#8f1e51d, event.job.topic=com/adobe/granite/workflow/timeout/job}, topic=com/adobe/granite/workflow/timeout/job, path=/var/eventing/jobs/assigned/fa67a921-cc59-4097-953a-a6e69ff5b718/com.adobe.granite.workflow.timeout.job/2018/10/3/16/38/fa67a921-cc59-4097-953a-a6e69ff5b718_92, jobId=2018/10/3/16/38/fa67a921-cc59-4097-953a-a6e69ff5b718_92]
03.10.2018 16:38:59.443 *DEBUG* [sling-threadpool-7e90cbd1-c78f-4aff-add9-eba2c792e8fe-(apache-sling-job-thread-pool)-22-Granite Workflow Timeout Queue(com/adobe/granite/workflow/timeout/job)] com.adobe.granite.workflow.core.job.TimeoutHandler process timeout job for work item /etc/workflow/instances/server0/2018-10-03/test-model_99/workItems/node1_etc_workflow_instances_server0_2018-10-03_test-model_99
03.10.2018 16:38:59.701 *INFO* [sling-threadpool-7e90cbd1-c78f-4aff-add9-eba2c792e8fe-(apache-sling-job-thread-pool)-22-Granite Workflow Timeout Queue(com/adobe/granite/workflow/timeout/job)] etc.workflow.scripts.test-timeout-handler$ecma
Test timeout handler /etc/workflow/scripts/test-timeout-handler.ecma is called
I'm trying to update Status information on assignments via Statusing Web Service (PSI). Problem is, that the results are not as expected. I'll try to explain what I'm doing in detail:
Two cases:
1) An assignment for the resource exists on specified tasks. I want to report work actuals (update status).
2) There is no assignment for the resource on specified tasks. I want to create the assignment and report work actuals.
I have one task in my project (Auto scheduled, Fixed work). Resource availability of all resources is set to 100%. They all have the same calendar.
Name: Task 31 - Fixed Work
Duration: 12,5 days?
Start: Thu 14.03.13
Finish: Tue 02.04.13
Resource Names: Resource 1
Work: 100 hrs
First I execute an UpdateStatus with the following ChangeXML
<Changes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Proj ID="a8a601ce-f3ab-4c01-97ce-fecdad2359d9">
<Assn ID="d7273a28-c038-486b-b997-cdb2450ceef5" ResID="8a164257-7960-4b76-9506-ccd0efabdb72">
<Change PID="251658250">900000</Change>
</Assn>
</Proj>
</Changes>
Then I call a SubmitStatusForResource
client.SubmitStatusForResource(new Guid("8a164257-7960-4b76-9506-ccd0efabdb72"), null, "auto submit PSIStatusingGateway");
The following entry pops up in approval center (which is as I expected it):
Status Update; Task 31; Task update; Resource 1; 3/20/2012; 15h; 15%;
85h
Update in Project (still looks fine):
Task Name: Task 31 - Fixed Work
Duration: 12,5 days?
Start: Thu 14.03.13
Finish: Tue 02.04.13
Resource Names: Resource 1
Work: 100 hrs
Actual Work: 15 hrs
Remaining Work: 85 hrs
Then second case is executed: First I create a new assignment...
client.CreateNewAssignmentWithWork(
sName: Task 31 - Fixed Work,
projGuid: "a8a601ce-f3ab-4c01-97ce-fecdad2359d9",
taskGuid: "024d7b61-858b-40bb-ade3-009d7d821b3f",
assnGuid: "e3451938-36a5-4df3-87b1-0eb4b25a1dab",
sumTaskGuid: Guid.Empty,
dtStart: 14.03.2013 08:00:00,
dtFinish: 02.04.2013 15:36:00,
actWork: 900000,
fMilestone: false,
fAddToTimesheet: false,
fSubmit: false,
sComment: "auto commit...");
Then I call the UpdateStatus again:
<Changes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Proj ID="a8a601ce-f3ab-4c01-97ce-fecdad2359d9">
<Assn ID="e3451938-36a5-4df3-87b1-0eb4b25a1dab" ResID="c59ad8e2-7533-47bd-baa5-f5b03c3c43d6">
<Change PID="251658250">900000</Change>
</Assn>
</Proj>
</Changes>
And finally the SubmitStatusForResource again
client.SubmitStatusForResource(new Guid("c59ad8e2-7533-47bd-baa5-f5b03c3c43d6"), null, "auto submit PSIStatusingGateway");
This creates the following entry in approval center:
Status Update; Task 31 - Fixed Work; New reassignment request;
Resource 2; 3/20/2012; 15h; 100%; 0h
I accept it and update my project:
Name: Task 31 - Fixed Work
Duration: 6,76 days?
Start: Thu 14.03.13
Finish: Mon 25.03.13
Resource Names: Resource 1;Resource 2
Work: 69,05 hrs
Actual Work: 30 hrs
Remaining Work: 39,05 hrs
And I really don't get, why the new work would be 69,05 hours. The results I expected would have been:
Name: Task 31 - Fixed Work
Duration: 6,76 days?
Start: Thu 14.03.13
Finish: Mon 25.03.13
Resource Names: Resource 1;Resource 2
Work: 65 hrs
Actual Work: 30 hrs
Remaining Work: 35 hrs
I've spend quite a bunch of time, trying to find out, how to update the values to get the results that I want. I really would appreciate some help. This makes me want to rip my hair out!
Thanks in advance
PS: Forgot to say that I'm working with MS Project Server 2010 and MS Project Professional 2010
I'm not sure if you guys test like this, but I'm a TDD guy and keep stumbling into wierd stuff. The timestamps are converted somehow by DJ, or the time zone... I don't know. Test example follows
I'm using delayed_job 2.0.3
data = {:value => 0.856, :timestamp => Time.zone.now}
job = MyMailer.send_later :send_values, data, emails
MyMailer.expects(:send_values).with(data, emails).once
job.payload_object.perform
class MyMailer
def self.send_values(data, emails)
end
end
OK, test expectation failure
unexpected invocation: MyMailer.send_values({:value => 0.856576407208833, :timestamp => Thu Nov 11 22:01:00 UTC 2010 (1289512860.94962 secs)}, ..
unsatisfied expectations:
- expected exactly once, not yet invoked: MyMailer.send_values({:value => 0.856576407208833, :timestamp => Thu, 11 Nov 2010 23:01:00 CET +01:00}...
with datetime it's similar, DateTime.now instead of Time.zone.now
got :timestamp => Thu Nov 11 23:13:33 +0100 2010 (1289513613.0 secs)
expected :timestamp => 2010-11-11T23:13:33+01:00
What's happening? How can I control it (do I want to)?
I thought I had the answer to this when I first saw the question. But I don't anymore, so here is a guess:
Since Time.zone.now, DateTime.now and Time.now are slightly different from each other, and Zone is something Rails has created (I think), could it be that ruby somewhere in your testing framework misses out on the zone-thingy? Time.zone.now.to_datetime has rescued me from similar stuff before. It lets you use zone, and you get the same format as DateTime.now witch lacks DateTime.zone.now.
Try: data = {:value => 0.856, :timestamp => Time.zone.now.to_datetime}