Kentico 11: Default Setting for Product Coupons > "Apply lower priority discounts" - e-commerce

Kentico 11.0.34 version. In the Product Coupons app, the default setting for "Apply lower priority discounts" is true/yes. Business logic stipulates that this should be set to false/no except in extraordinary circumstances. Because this option is hidden under the Discount processing tab at setup, it is often missed. Is it possible to change the default of this setting? Discount Processing Setting Default

Default value unfortunately can not be changed via UI. You can get to property of discounts table in the UI (Modules -> E-commerce -> classes -> discounts), but general attributes can not be modified and are grayed out. Without DB hacks or direct change of class configuration in CMS_Class table it can not be done and I would like to avoid that (upgrades etc.) In code, default property getter if value is null will return true.
What is the situation in which you want this to be disabled? There could some things achieved via code and attached handlers for example, but it depends on situation.

Related

Add Validation in Aurelia dynamically

Is there a way to add Validation to a property on my VM "dynamically" (i.e. sometime after I register the initial rules on the VM)?
Currently, I'm registering the rules in the constructor of the VM, then a little while later, after the user has entered a bunch of data, I need to show a new field (using if.bind) and want to add validation depending on the result of a web api call..
Wondering if there's an API for this that I've missed?
You can achieve it without dynamically adding rule but instead you can use satisfiesRule and when, see it here in section Conditional Validation. satisfiesRule will only evaluated if the property that attached to it is already pass.
when will only evaluated the rule if the condition is true.
Additional link.
If you're using bootstrap, you can find this useful.

DDD - How should the domain rules be designed so the upper layers know when a rule was broken?

Example : ShoppingCart entity has a rule that no more than 10 items can be added . The shoppingCart will have a method addItemToCart(item) that will check if it the limit was not exceeded. If the cart limit is exceeded the cart should somehow inform somehow the upper layer calling that method that a specific business rule was broken.
One thing that comes in mind is to use exceptions but these seem an unproper use of exceptions. How should the messaging be done? What patterns could help for this problem , keeping the domain unrelated to the other layers and properly encapsulated ?
If the rule is max 10 items in the cart, then ShoppingCart should expose isFull() so upper layers can check before calling addItem(). Or disable Add button, or whatever - ShoppingCart doesn't know how the rule information is used and shouldn't assume it will only be required when addItem is called. As a safety check addItem can throw an exception but this shouldn't be the primary mechanism to communicate to upper layer.
There isn't a recipe for that, it really depends on your app. For your specific example I believe things are quite simple: ShoppingCart is pretty much a container and even that it's a domain concept it's still a container. Also the UI should be aware of this rule too, so it shouldn't allow for a greater number of items than it suppose to accept.
But let's say the shopping cart POST model get to the controller. It's easy to have a service or use directly the ShopppingCart object to validate the input. The point is, you expect this kind of situation so you deal with it as fast as possible. but if you decide that the UI shouldn't allow this to happen in the first place, then the ShoppingCart should throw an exception, because it's a bug (UI permitted an invalid operation).
Personally, I wouldn't have a ShoppingCart domain concept modeled. The ShoppingCart would be an input model used to create an Order from it.
As a thumb rule, if I expect some situations (which require to give feedback to the user) then I'd have some validation before I'm using the data to update the domain. The domain objects should throw everytime a business rule is violated. Once again, there isn't a recipe, I'd probably do different things in different apps.
The same way as in any other program: choose a method that works well with your team and with your implementation environment. Exceptions work fine.

Worklight - Updatable static content

I have this requirement : My WL application have a set of static pages that might be updated any time. Originally the source of all static content is a desktop page that will be transformed by xsl to a mobile friendly content. The problem that I don't want to do that on each request (HA requirement).
I want to get some inspiration on how to architect that without using direct update mechanism (don't want the end user to get notified of these updates).
I should note that pages will change rarely every few month maybe.
I'm thinking about 2 ways of doing that :
1- Making the transformation on adapter side and rely on WL caching so that transformation is not made each time (does that exist ?). But how the adapter will get notified of page change and flush the cache ? Should I program some advanced java based adapter ? (Storing in the cache and having a kind of a job that scans every day for content changes ?)
2- Doing it mobile side but I don't know how to get notified of changes !
Is your only problem with Worklight's Direct Update that the user is being notified and is required to explicitly approve the transfer?
In this case why not use the option of Silent Direct Update?
The property you're looking for is updateSliently set to true in initOptions.js.
For this to work it is required, obviously, that connectOnStartup will be set to true as well.
perhaps what is doable is to use an adapter to fetch the HTML (or whatever it is) and save it to the device's local storage and then have the app display this content, this way you do not alter the app's web resources and not trigger Direct Update.

How to find hidden change sets

This question is linked to :
Why can't all change sets be found when accepting change sets?
If RTC discovers that by accepting a change set some of the change sets which depend on this change set will not be accepted, is it possible to view what these change sets are ?
It seems very risky to accept a change set and not be 100% sure that the change sets being accepted contain same source code file changes as was intended by developer who delivered the change sets ?
What you can do is adding the repo workspace of the developer having delivered on the source stream.
You would add that repo workspace as a flow target of your own repo workspace (the one you are using for the merge)
By setting that new flow target as current, you can quickly see what change set you are missing.
Of course, the real issue is that what I just proposed doesn't scale: if you have multiple developers having made partial delivers (with missing intermediate change sets), then you would need to have a look in turn to each developer's repo workspaces.
That is why you have since 2007(!) the "blocker" Work Item "Enhancement 24822":
"Confirm Content Accept" dialog should be more specific (offer to fill in gaps when a gap exception occurs)
... but it is still unresolved, even in the latest RTC4.x.

Can I associate a change set with a work item after it has been delivered?

If I deliver a change set to a stream and not associate it with a work item can the change set be associated with a work item after it has been delivered ?
Yes.
The changeset itself is closed upon delivery to the stream.
But its associated work-item(s) is not: you can add or remove one or several work-items in association with the delivered changeset.
That being said, I have a special hook which makes that association mandatory on deliver: ie, you cannot deliver without having first associated your change set first to a Work Item.
I am not sure if that hook is a custom one for my organization, but here is where you can check if it is there:
It is in the Project Area administration, under
Team Configuration /
Operation Behavior /
Source Control /
Deliver (client) /
Preconditions and follow-up actions are configured for this operation /
Require Work Items and comments