Did someone has a problem with email templates?
In my case when I use email template in Flow builder for trigger "checkout.order.payment_method.changed" email template with type "order confirmation" doesn't work properly. Problem with variables: currency and addresses are null but other variables works properly.
Interesting when I use the same template in Flow builder for trigger "checkout.order.placed" all vars working properly.
p.s. I've updated all extensions and my Shopware version is v6.4.9.0 Stable Version
Maybe it's a Shopware bug or conflict between plugins?
There are some inconsistencies regarding the data available between different Flow-Builder Events. I noticed something similar and created an issue for it here.
Maybe you can add your case there as this sounds related.
Without knowing the exact content of your order confirmation template, eg if it is the default content or if you made changes, it is hard to tell why this wouldn't work. I tested this on the latest release as of today 6.4.13.0 and the combination of said trigger and template seems to work fine. Looking at the history of the OrderStateChangeEventListener, the criteria for the order should've included currency and addresses associations for a while already, including your version. As #newgennerd already said there could potentially be differences between the criteria used for fetching order for state change events and those used for order placed events, as the latter would be the common use case for the order confirmation. So you should keep that in mind.
Related
I am using the latest versions on 2sxc (11.05) and the Content App on DNN 9.06. The Content-Type for Locations does not have a field for Region (or State). Is there already something in place to account for that to get Canadian or US addresses to output normally? I realize I can add the field and then maybe use the Dropdown from Query to hook it up to DNN's list of Regions, and then modify the Views accordingly...
But that seems like a lot of work for something that might already be built in (and I just don't see it?). Or is there another easy way to tackle this?
Truth be told - we never needed that so far, so it doesn't exist.
Is this necessary for maps to work, or just another field which a standard us-address needs? I'm curious because neither outlook nor SharePoint seem to require such a field, so I never really thought about it.
BUT: if you do implement it, please do share it back with us, so we can publish it.
Note that if this is important, a possibly nicer solution would be to use a public api somewhere which provides this information, as it's most certainly more complete & up to date for this purpose. If this is the case, ping me and I'll implement a string-dropdown-from-json or something like that :)
I've been looking for any documentation which suggests whether there is a way of saving Document Settings & CustomProperties such that they're automatically propagated to co-authors of the current document.
I've done some testing which suggests that's these settings aren't automatically propagated even when the document is saved. I'm also storing XML inside the document so I'm concerned that this won't be propagated as well. Since I'm doing this in Excel, I could always create a hidden sheet to store the properties in and have a watch on the table (or some similar set-up) but this isn't really the avenue I want to go down since some user could easily come along and delete the hidden sheet or manipulate its contents.
Has anyone come across this issue and managed to find a solution to it?
Welcome to Excel JS world.
I have verified this issue, it looks like a co-auth bug in settings and custom properties API. We have created 2 bugs (BUG 4173957 and BUG 4173952) for tracking this issue.
As a workaround, you could use our beta API worksheet custom properties, which is in preview, this API support co-auth. You could try it out, please let me know if you have any suggestion on this API. thanks.
We have a complex scenario which requires a timer job to run after content deployment to a SP 2010 site collection. The timer job automatically deactivates/reactivates a branding feature which is responsible for setting the master page for the site collection, among other things.
We have had several feature upgrades along the way, and neglected to call .Update() on the feature in that specific site collection. So all of the updated CSS, master page, page layouts etc. are out of date on that SC.
The strange part is that when I checked the version number of that feature in this SC, it shows as the latest version. The custom upgrade action clearly didn't run and update the files, because nobody called .Upgrade().
One of my colleagues suggested that the deactivate/reactivate process done by the timer job would update the version number, meaning that I can no longer call Upgrade()!
Is that true? Does a deactivate/reactivate cycle for a feature automatically update the feature version number?
Is there an easy way to fix this mess? Some way to decrement the version number programmatically, then call Upgrade()??
On 1: No. Feature deactivating / activating does not trigger an update. See this article by Chris O' Brian: http://www.sharepointnutsandbolts.com/2010/06/feature-upgrade-part-1-fundamentals.html
Feature upgrade does NOT happen automatically (including when the
Feature is deactivated/reactivated)! The only way to upgrade a Feature
is to call SPFeature.Upgrade(), typically in conjunction with one of
the QueryFeatures() methods. My tool which I’ll go on to talk about is
a custom application page which helps you with this part – note there
is no STSADM command, PowerShell cmdlet or user interface to do this
out-of-the-box.
Is your timer job cycling the feature activation with Force? Then, yes, it is triggering the feature upgrade/feature update see the following screenshot from SPFeature.Activate (see my yellow marking):
Why the feature version is incremented, I'm not sure. When you have a feature, install a new feature version and activate / deactivate, the feature version stays the same unless you run an Upgrade, see also this related question stating the same: https://sharepoint.stackexchange.com/questions/41476/feature-upgrading-question
I'm guessing your timer job is using force? Otherwise I'm not quite sure what is happening.
On 2: Don't know if it is possible to decrease the version number, but the safest way would be to just create a new version including a grand "clean up" feature receiver which sets everything correct, i.e. checks which steps of the feature upgrade have happened already (e.g. new list created, new content type added) and which haven't. Depending on that just execute the same steps again which have not executed yet. For the latter part you can fortunately use the existing code, so you would only need the "clean up" or checking code.
After some testing I found that simply deactivating and reactivating the feature will increment the version number and completely screw up your upgrade! I even watched the update come through in the content database. As soon as you deactivate/reactivate the updated feature, the new version number pops into the content DB. Of course the upgrade doesn't actually run, it just increments the version number.
This means that if you then call .Upgrade() it won't work because SharePoint thinks it's already been upgraded!!
To fix this I updated the row in the content database to set the feature version back to 0.0.0.0 for that particular web and then I could run .Upgrade() just fine....but that's not exactly a supported solution. If anyone else has a better idea drop a reply.
EDIT: might be fixed in latest Xcode 4.0.2 (just released) - I'm downloading this out now, and will re-edit once I've tested it.
Create two entities (call them "Manager" and "Employee", to stick with Apple's docs).
Create a relationship, "worksFor" from Manager (1) to Employee (many), and mark it as "not optional". (you'll probably need to create 2 relationships, mark 1 as inverse of other)
Hook up an interface using IB, according to Apple's original docs (NB: these don't work any more, but here's an almost exact recreation of the basic setup in Xcode4: http://rgprojection.blogspot.com/2011/04/xcode-4-and-core-data-macos-x.html) and use Bindings (as described in the linked post) to create/add/delete the objects.
Now try to save. ERROR: "worksFor is a required property".
In previous versions of Xcode, this worked as expected: you'd told Xcode that there was a bidirectional relationship, you told it that it was required, and so when it added the "Employee" to the "Manager", it automatically hooked-up the inverse.
Has anyone else worked out how to make Xcode4 do what it's supposed to? Is it an Xcode4 bug? I know that some of the CoreData support in Xcode4 has been deleted, with no replacement (yet), so I'm wondering if this has been deleted too?!
EDIT: here's another project, one I made from scratch, same problem. Although (xcode4 bug, definitely!) this time I created the Relationship in the "grid" editor view rather than the "tree graphical" view... and the generated source code for objects was different (should not be the case, obviously)
second project screenshot
EDIT2: StackOverflow was showing the screenshot above, but has now removed it, you'll have to click on the link. Sorry.
I haven't seen the problem you describe and I've created several data models under Xcode4. It appears to work just like it did in previous versions in that regard. I think you've got something else going on.
Xcode 4.0.2 seems to have fixed the problem - everything works as expected now, with no changes to code :)
Is there any way to enforce a template in Bugzilla to guide users fill in bugs descriptions ?
Actually, i'd like to put some markup texts in the bug description field and avoid the creation of custom fields.
I've installed version 3.2rc1.
Indeed, just check ../enter_bug.cgi?format=guided , which forms an example of the template feature. Half the work is already done for you.
The mechansism described under 6.2.5 Particular Templates (under the section called bug/create/create.html.tmpl and bug/create/comment.txt.tmpl) works pretty well for us. Even though you say you don't want to create custom fields, adding some arbitrary HTML is easy enough.