tracker issue : CF-3434100

@Adobe, cfschedule needs action="create". Issue is b/c action="update" is currently used for both creation -and- updates. This causes confusion and other issues. Thanks!, -Aaron

Comment by External U.

+1, pls add action="create" (action="update" should only update, not create)

Vote by External U.

action="update" also clears the Last Ran timestamp. :(

Comment by External U.

This is by design. As this action re-creates the schedule task. For updating particular attributes of an existing task it is recommended to use admin UI

Comment by Uday O.

How is dataloss by design? If I am just updating one part of the scheduled task I wouldn't expect the entire task to be reset to defaults.

Comment by External U.

This is not acceptable! If it's by design, then it's a bad design decision. <cfschedule action="update"> should not reset existing customized values to their defaults. Unacceptable!

Comment by External U.

see my comment. unacceptable!

Vote by External U.

This will be treated as an enhancement. Perhaps introduction of action='create' which will behave like action='update' and 'update' action will do what you all are expecting

Comment by Uday O.

Yes, probably the scheduled tasks shouldn't have been designed like this. But they have been like this since ColdFusion 5 and changing this behavior would mean that all the applications using cfschedule would break which we can't do. We need to decide a new attribute which will decide whether we should delete the current and create a new or update the existing task. Any suggestion for the attribute name? or any other suggestion?

Comment by Rupesh K.

Hi Uday and Rupesh, Regarding: "This will be treated as an enhancement. Perhaps introduction of action='create' which will behave like action='update' and 'update' action will do what you all are expecting" Perfect. Has an ER been filed yet for CF12 (since CF12 can break backward-compat)? Thanks!, -Aaron

Comment by External U.

Thanks Aaron. We will be re-opening this bug when we start the work on the next version. There is no need to log another E/R

Comment by Rupesh K.

Hi Rupesh, You're welcome. And awesome, thanks! -Aaron

Comment by External U.

Hi Rupesh, I see this ticket is still marked Closed, but I'm guessing work on CF12 has already begun? I would certainly hope so =P Could this ticket please be re-opened? Thanks very much for considering!, -Aaron

Comment by External U.

Hi Adobe, You promised me that I did not need to log another ticket. You said this ticket would be re-opened. You said that 4 years ago! Can you please do what you said and re-open this ticket? Thanks!, -Aaron

Comment by Aaron N.

Hi Aaron , We are looking into this ticket. We can't change the behavior of 'update' action as it will have backward compatibility issue. What name do you suggest for new action : edit, realupdate,fecthandupdate,updatenodelete etc Another way to handle backward compatibility , would be adding a new attribute . <cfschedule action=update *delete*=no> This will not reset properties (new behavior)  <cfschedule action=update *delete*=yes> This will reset (old behavior). This will be default behavior. Please let us know your suggestions.  Thanks, Uday.

Comment by Uday O.

Hi Uday, Thanks very much for the follow-up! I didn't see your reply b/c tracker's email notification system is broken again :/ (@TrackerTeam: can u pls fix?) Its undocumented resetting of unspecified properties isn’t the only action=”update” issue. It also preserves some metadata (like STATUS) but clears other metadata (like LASTFIRE). It’s a dirty update, whose description is misleading and whose use should be avoided IMO. For those wanting the expected behavior of 1) existing metadata preserved and 2) existing properties preserved, I’d propose action=”modify”. And for those wanting an exception to throw if a task already exists, I’d propose action=”create”. I’d use and recommend both of those over the action=”update” spaghetti. I’d prefer not to have an action=”delete” and delete=true which net the same result. Other tags like ldap and the Exchange tags use action=”modify”, so at least that action attribute value has some precedence. Thanks!, -Aaron

Comment by Aaron N.

Hi Adobe, Received this email: ---- Issue - https://tracker.adobe.com/#/view/CF-3434100 Frequency updated from 'Most users will encounter' to an empty value ---- Who made that change? Please revert to "Most users will encounter"! B/c *anyone* re-saving their task (via CF Admin or cfschedule) can break their task if they're unawares to this bug. Just b/c it's been 6yr since this ticket was created doesn't mean it suddenly _doesn't_ affect most users. Thanks!, -Aaron

Comment by Aaron N.

Hi Adobe, Are you adding action="modify" (for modifying a task) and action="create" for creating a task? The action="update" is a complete mess. No one should use it, IMO. I'd deprecate it eventually, if it were up to me :) Thanks!, -Aaron

Comment by Aaron N.

Hi Aaron, We have added two new actions : CREATE & MODIFY  CREATE will create a fresh new task. If task already exists, it will thrown an error MODIFY will modify existing task while retaining its old values. If task does not exist, it will throw an error The action "UPDATE" remains the same . The fix for this will be available in the next update of ColdFusion 2018.   Thanks,  Suchika  

Comment by Suchika S.

Hi Suchika, Sweet!!!! This will be very helpful, thank you very much!! -Aaron

Comment by Aaron N.

Hi Suchika, Hopefully these are also done?: 1) CF Admin's "Edit Task" page should now use action="modify". 2) CF restart, and action="modify", should now honor LastRan metadata, and not mistakenly misfire a task. If yes to both, then that'd resolve CF-4197250. I will add repro case to CF-4197250. Can you check please? Thanks!, -Aaron P.S. And CF2018's future Admin API should also support action="modify" functionality, right?

Comment by Aaron N.

Hi Aaron, The fix for this bug will take care of :  1) CF Admin's "Edit Task" page should now use action="modify". For 2) CF restart, and action="modify", should now honor LastRan metadata, and not mistakenly misfire a task, I will re-open the bug CF-4197250 Thanks, Suchika

Comment by Suchika S.

Hi Suchika, Sweet!! Thank you very very much!! =D -Aaron

Comment by Aaron N.