Hello Devs, I have logged Jira for this improvement. Here is the link for the same: https://issues.apache.org/jira/browse/OFBIZ-11035
Soon, I will add a patch for this. Suggestions are most welcome. Thanks! -- Thanks & Regards Pawan Verma Technical Consultant *HotWax Systems* *Enterprise open source experts* http://www.hotwaxsystems.com On Wed, Mar 20, 2019 at 4:01 AM Scott Gray <[email protected]> wrote: > Hi Rishi, > > Thanks for taking a look! > > My only concern with using runAsUser would be that recurring services > typically use the "system" UserLogin and using this approach might require > multiple UserLogin/UserPreference records if there are different recurring > services using different timezones. > > Also it should be fine to use RunTime data, as of now I could not see no > > issues with that. The only thing is not possible is if system requires to > > run a service always on specific time zone values and runtime could have > > different values. > > > > Yeah I think I don't like the RuntimeData idea after thinking about it, an > opposite use case to my one might cause problems, e.g.: > I want a report to run at midnight UTC every night but I want the > timestamps converted to Pacific Time because that's where my users are so I > would like to use timeZone "America/Los_Angeles" or similar for the service > context. > > So I think unless other ideas come along, my preference would be for adding > a new field to JobSandbox. I'll create a ticket within the next few days > and try to come up with a better field name. Maybe "recurrenceTimeZone", > seems clear and somewhat concise. > > Thanks > Scott > > On Tue, 19 Mar 2019 at 22:24, Rishi Solanki <[email protected]> > wrote: > > > Hello Scott, > > Can we think of using JobSandbox.runAsUser='myuser' and UserPreference. > > > > <UserPreference userLoginId="myuser" > > userPrefGroupTypeId="GLOBAL_PREFERENCES" > userPrefTypeId="defaultTimeZoneId" > > userPrefValue="UTC"/> > > > > Also it should be fine to use RunTime data, as of now I could not see no > > issues with that. The only thing is not possible is if system requires to > > run a service always on specific time zone values and runtime could have > > different values. So having value in database makes sense to me, and okay > > with #1 of having it on JobSandbox level. > > > > I proposed UserPreference so that no field added with possible solution > and > > we can achieve it. Could not think of any side effect as of now if we use > > it only for schedule, in case the same can be use for different purpose > > while log in, then it may have several side effects. > > > > Best Regards, > > -- > > *Rishi Solanki* | Sr Manager, Enterprise Software Development > > HotWax Systems <http://www.hotwaxsystems.com/> > > Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, > > Indore, > > M.P 452010 > > Linkedin: *Rishi Solanki* > > <https://www.linkedin.com/in/rishi-solanki-62271b7/> > > Direct: +91-9893287847 > > > > > > On Tue, Mar 19, 2019 at 10:56 AM Scott Gray < > [email protected]> > > wrote: > > > > > Hi all, > > > > > > Trying to decide on the best way to define a temporal expression for a > > > recurring job where the temporal expression should be evaluated using a > > > timezone other than whatever the default timezone is for the system. > > > > > > Use case is having a system that runs on UTC time, but needs to send a > > > report at 5pm Pacific Time everyday regardless of whether or not > daylight > > > savings is in effect. > > > > > > I see two options: > > > 1. Add a field to JobSandbox such as tempExprTzId (or better name!) > > > 2. Use whatever timezone is available in the RunTime data service > context > > > > > > #2 seems simplest but I'm not sure if there's scenarios where the > service > > > should be run with one timezone while the recurrence should be > scheduled > > > based on another? I can't think of any. > > > > > > Regards > > > Scott > > > > > >
