I'm trying to override the "EQUALS" or "GREATER" comparator in Sap commerce cloud (hybris), and I was wondering which is the correct way to do it. I want to modify this field as when comparing the equals with a date, it does not take into account the hour of the date. I would like to override the comparator to have the hour into account.
For equals, there exists an out of the box configuration you can use to ignore the time aspect. equalsComparesExactDate
<advanced-search:field name="date">
<advanced-search:editor-parameter>
<advanced-search:name>equalsComparesExactDate</advanced-search:name>
<advanced-search:value>false</advanced-search:value>
</advanced-search:editor-parameter>
</advanced-search:field>
According to the documentation, there is also comparesExactDate, for the other operators to ignore the time component
<advanced-search:editor-parameter>
<advanced-search:name>comparesExactDate</advanced-search:name>
<advanced-search:value>false</advanced-search:value>
</advanced-search:editor-parameter>
This should work
<advanced-search:field name="date" selected="true">
<advanced-search:editor-parameter>
<advanced-search:name>comparesExactDate</advanced-search:name>
<advanced-search:value>true</advanced-search:value>
</advanced-search:editor-parameter>
<advanced-search:editor-parameter>
<advanced-search:name>equalsComparesExactDate</advanced-search:name>
<advanced-search:value>false</advanced-search:value>
</advanced-search:editor-parameter>
</advanced-search:field>
Related
We are sending out account invitation messages to users, using Accounts.sendEnrollmentEmail. In some cases, users fail to click the link for some time. In those cases, we have to re-send the invitations, making extra work for admin users.
The Meteor Accounts package seems to use DEFAULT_PASSWORD_ENROLL_TOKEN_EXPIRATION_DAYS to expire activation links. Is it possible to override this value or disable it?
As I found in the code it is a const with a fixed value.
You therefore won't be able to override it by default.
However you still have some options here.
Override the accounts-base package and use values from process.env or Meteor.settings for the expiration variable.
Use additional token data in sendEnrollmentEmail and place a custom expiration date there. Then use onEnrollmentLink to make a custom validation of the expiration date.
Use a custom Collection to store expiration dates and check them in onEnrollmentLink
If you prefer the first option it would be great if you also open a PR on the Meteor repo so others will benefit from it.
We were able to fix the issue with the following, e.g. in accounts.js:
Accounts.config({
passwordEnrollTokenExpirationInDays: 60
});
I'm working with moment and moment-timezone and I don't get it. Can anyone explain me why this happens?
THIS (which is what I want):
moment('2018-11-28T00:00:00.000-02:00').toISOString()
Prints 2018-11-28T02:00:00.000Z
BUT:
moment('2018-11-28T00:00:00.000').zone('-02:00').toISOString()
moment('2018-11-28T00:00:00.000').utcOffset('-02:00').toISOString()
Both print 2018-11-27T23:00:00.000Z
PD: My zone is GMT+1.
Why are different? it is not supposed to be equals?
How do I set the offset (not in the constructor but with a method after I have de moment object)?
Thanks! BR
As I can see, you want to keep the existing time of day when using utcOffset method. It accepts a second parameter, which is a boolean. As the documentation says:
Passing true will keep the same local time, but at the expense of choosing a different point in Universal Time.
// "2018-11-28T02:00:00.000Z"
moment('2018-11-28T00:00:00.000').utcOffset('-02:00', true).toISOString();
For more information check the documentation
I want to customize the standard drill-down functionality and add a text parameter to the drill-down URL. I will then parse and use the parameter in the SysStartUpCmdDrillDown or EventDrillDownPoller class like the solution provided by Jan B. Kjeldsen in this question.
The standard drill-down link is dynamics://Target/?DrillDown_RecID/ :
dynamics://0/?DrillDown_5637230378/
In previous versions of AX it was possible to modify the RecId to custom text and parse the text once the client is started:
dynamics://0/?DrillDown_0MenuItemName=PurchTable&FieldName=PurchId&FieldValue=P000044
Unfortunately, in AX 2012 the RecId is checked before the client is started and if it is not a valid int64, the drill-down event is not sent to the client. Since it is not possible to change the RecId to anything other than an integer, #Alex Kwitny suggested in the comments at that same question that you can add the custom text to the drill-down target like this:
dynamics://0MenuItemName=PurchTable/?DrillDown_5637230378/
The problem I experience with this is that the link now gets confused about which instance to start.
If the target is equal to the value in the System Admin -> system parameters -> Alerts ->Drill-down target, a client with the correct server instance is started. When I append the text with my custom text, it always starts the default instance(Which could be different from the instance I intended to start). While this is not ideal, I could work around this issue.
The bigger problem is that it now always starts a new session of the default instance, even if a client session is already started. As far as I can see I cannot write X++ code to solve this issue since the server instance is determined before any code in the client is executed.
My question is this - How can I add custom text to the drill-down link while preserving the way the client instance is started: If a client for the instance is already open, it should process the link in the open client, and not start up a new client of the default instance.
You should probably come up with another solution as mentioned in this post, but there could still be a way.
The URL has two objects that can be modified:
dynamics://[Drill-down target(str)]/?Drilldown_[Int64]
According to you, if you modify the [Drill-down target], then it launches AX using the default client config, and that is behavior that you don't want. If you have a matching [Drill-down target], it'll launch in the open client window, which is behavior I can't confirm, but I'll take it at face value and assume you're correct.
So that means the only thing you can modify in the URL is [int64]. This is actually a string that is converted to an int64 via str2int64(...), which in turn corresponds to a RecId. This is where it gets interesting.
This work all happens in \Classes\SysStartUpCmdDrillDown\infoRun.
Well, lucky for you the ranges for the objects are:
RecId - 0 to 9223372036854775807
Int64 - -9223372036854775808 to 9223372036854775807
You can call minRecId() and maxRecId() to confirm this.
So this means you have -9223372036854775808 to -1 numbers to work with by calling URLs in this range:
dynamics://0/?DrillDown_-1
to
dynamics://0/?DrillDown_-9223372036854775808
Then you would modify \Classes\SysStartUpCmdDrillDown\infoRun to look for negative numbers, and fork to your custom code.
HOW you decide to user these negative #'s is up to you. You can have the first n-digits be a table id or a look-up value for a custom table. You can't technically use a RecId as part of that negative number because in theory the RecId could get up that high (minus 1).
When I create or update record on sails it write this at updateAt:
updatedAt: 2014-07-06T15:00:00.000Z
but I'm in GMT+2 hours (in this season) and update are performed at 16:00.
I have the same problem with all datetime fields declared in my models.
How can I set the right timezone on Sails (or eventually Express) ?
The way I handled the problem after hours of research :
Put
process.env.TZ = 'UTC'; //whatever timezone you want
in config/bootstrap.js
I solved the problem， you should setting the MySql options file to change timezone to UTC
in the config/connections.js
setting at this
devMysqlServer: {
adapter: 'sails-mysql',
host: '127.0.0.1',
user: 'root',
password: '***',
database: '**',
timezone: 'utc'
},
Trying to solve your problem by setting the timezone on your server is a bit short-sighted. What if you move? Or someone in a different country accesses your application? The important thing is that the timestamps in your database have a timezone encoded in them, so that you can translate to the correct time on the front end. That is, if you do:
new Date('2014-07-06T15:00:00.000Z')
in your browser console, you should see it display the correct date and time for wherever you are. Sails automatically encodes this timestamp for you with the default updatedAt and createdAt fields; just make sure you always use a timezone when saving any custom timestamps to the database, and you should be fine!
The best architecture planning here, IMO, is to continue using Sails.js isoDate formatting. When you're user's load your website/app the isoDate will be converted to their client/browser timezone which is usually set at the OS level.
Here's an example you can test this out with. Open a browser console and run new Date().toISOString() and look at the time it sets. It's going to be based of off the spec for isoDate 8601 (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString).
Now, change your system time to a different time zone or simply change your hour on the time and save (you shouldn't have to reload if you're using chrome console). Run your command in the console again new Date().toISOString() and you'll get an adjusted time appropriate to the time you just changed.
If you'd like to continue on proving to yourself the time Sails.js is appropriate to use, use Moment.js on an isoDate that is stored in your database (created by waterline ORM) like so moment("2016-02-05T22:36:48.800Z").fromNow() and you'll notice the time is relative to your system time.
I've come to grips with not setting a timezone at the app level (I see why the sails authors did it that way), however I've been having a rough time performing a simple date match query. I'd assume that if you create a record using the default blueprint methods (this one containing an extra datetime field over the defaults), passing in a date, that you'd be able to pass in the same date in a get query and get the same record.
For example, let's say the datetime field is called "specialdate". If I create a new record through the api with "specialdate" equaling "06-09-2014" (ignoring time), I haven't been able to run a find query in which I can pass in "06-09-2014" and get that record back. Greater than queries work fine (if I do a find for a date greater than that). I'm sure it's a timezone offset thing, but haven't been able to come up with a solution.
I'm integrating s2member as membership plugin to an existing wordpress site.
It is easy to generate the paypal button so the user is subscribing, for exemple, for one year of membership.
Our membership will effectively be valid for one year, but from a fixed date to another fixed date.
Basically, the membership must be valid from 1st of june (2011) to may 31 (2012). The user may have from may 15 to june 15 to subscribe, but we want the membership to end on may 31, whatever is the date the membership is purchased.
Is it possible?
Thanks ;)
Yes, it is possible. From the documentation:
s2Member uses its built-in Auto-EOT System. EOT = End Of Term. Whenever you generate a PayPal® Button with s2Member, you'll configure a length for the Subscription. Depending on the type of Subscription you choose ( recurring, non-recurring, lifetime, or fixed-term ); s2Member will either use PayPal's IPN/subscr_payment,subscr_cancel,subscr_eot notices, or it will set an Automatic EOT Time, which is processed automatically by s2Member via WP_Cron. For each Member, you can also override the EOT Time, by forcing a specific expiration date. To manually adjust the EOT Time for a specific Member, go to: WordPress® -> Users, and click the Edit link next the Member you want to work on.
That said, there is likely a date field in an s2Member table that you can override with a default value of May 31. Granted, additional constraints will need to be enforced programmatically to account for the rest of your membership logic. Example:
if ( date() >= $signupStartDate and date() <= $signupEndDate ) {
processForm();
} else {
die ( "You cannot sign up right now. Try again on " . $signupStartDate . "." );
}