I have a webhook setup but seems to have some issues with dm:version:deleted not always being triggered.
As far as i can see it is active, but most often just does nothing when i delete a file on BIM360.
I also have other webhooks active like dm:version:added, dm:version:moved, etc.., that all seems to work as they should.
My question might therefore be, are there any different setups in dm:version:deleted compared to the other webhooks?
Are there any known issues with the firing of the dm:version:deleted?
Would there be another way to detect the deletion of files on BIM360, other than checking all files in a project?
Thank you in advance.
BIM360 is using immutable file operations a “file delete” operation is not really deleting a file but is creating a new version of that file/lineage with a specific type
versions:autodesk.core:Deleted
so you should check for a file modified event and have a look into the type of the new version. Look for
dm.version.added
events when the file is deleted on your end and not
dm:version:deleted
events.
Related
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.
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.
It appear that the docid's changed for all google drive documents on our google apps domain...
Will it change again?
Why was it changed? (my google/yahoo/bing searches on this subject turn up nothing useful - is no one else experiencing this? For me it seems to have happened at around Jan 16/17th)
And most importantly for now:
Is there a way to cross-reference all of the old docid's to the corresponding new docid's?
Found out some more info. The root cause is a migration from the old presentation editor to the new one. The new editor has been the default for a while, but to complete switch over all the older presentations needed to be converted. For various technical reasons, it wasn't possible to do this without creating new file entries for each presentation. This happened once before about 6 months ago when the same thing was done for documents.
It is possible remap the IDs by checking the change feed. The delete & create will appear as separate events, but if you look for deletes followed by a create of a file with the same title you can build up a mapping of the file IDs. Not entirely foolproof, but its a one time operation.
So turns out IDs aren't quite as immutable as made out to be...
I am using my ccnet which is configured with the clear case
and everything is working fine as expected,but i am unable to see
anything in the "ViewProjectModificationHistory".whenever i click this
tab,i see a message which tells that :"No history Data found, make
sure you use the modificationHistory Publisher for this
project".Infact i had added under the tag.And to my
suprise,when i open this same link in the other persons system,it
opens well and fine and see all the modification history recorded.
So can anyone please tell me what could be this issue and how can it
be resolved?
Thanks and regards
Maddy
You should check your build history file. This will contain the XML data that feeds these reports. In particular, check the modifications/modification nodes to see if they are populated or not.
My guess is that the modifications are not there - so there may be nothing to display.
Another gotcha I have caught myself doing is not actually checking that there was in fact changes committed since the last time I built a project.