I'm deleting an instance of an entity and depending on the value of an option set in it, I wish to carry our different course of action. The problem is that the field isn't changed, hence, not provided to the plugin's target.
How can I easily tell the stupid plugin to fetch all the fields?
The way I do it now is to use pre-image but I'll be showing the plugin to some rookies and they will definitely not like it. And they won't believe me that's the way to go, for sure, because they're a cocky bunch.
Is there a work-around for that?
Using the pre-image is the suggested way in this scenario, the alternative is to instantiate a service factory in order to get an IOrganizationService and retrieve the entity using the target's Id.
It is part of the IPluginExecutionContext (of which Target is one part.) I think the beginners are confused if they think of Target as anything more than a property of IPluginExecutionContext.
It wouldn't make sense to have these values as part of Target, because then it would cause an update of the field to its current value - if you forced it into Target you would see the update in the audit details.
Thus, CRM has PreEntityImages, Target, and PostEntityImages, if Target was used the way "they" want it would not be able to differentiate between values being updated, previous values, and the final result of the entity.
Related
So as a project matures it will almost certainly be necessary to modify attributes of the resource definitions to cope with additional requirements.
Let's use two trivial examples - to add a country code to a client address, or to remove a middle initial and swap in a middle name field instead.
Currently if the resource definition changes, composer won't read whatever values are extant in the repository. I didn't exhaustively try all combos, but have had to reconstitute my blockchain at least twice because of this problem.
Is there a way to mark fields either as "new" or "deprecated" to get past this that I overlooked? It will be hard to make a case to move a system that can't be changed forward to production.
In the same vein it doesn't seem to like empty or null strings much (at least for participant attributes). Having an "optional" override somewhere would save a lot of extra bounds checking in my application. Is there one of those I missed too?
So you can use the APIs or REST to expose the legacy data? You may be referring to Playground above (its not really a tool for looking at production data, its for model prototyping/sandbox/testing type stuff).
On optional question - can just add that the field is optional in the model - example here -> https://github.com/hyperledger/composer-sample-networks/blob/master/packages/pii-network/models/pii.cto#L20
stack guys.
Recently, I process the net request with restkit, but if I want to add some key-value pairs that doesn't exist in the source representation, (such as the "userid", which is for user switch), I must add this in the success block, this is very boring. So, is there any convenient way to solve this?
Your best option is probably to override willSave method in your managed object subclass and, if the id isn't set, create and set it. This will update the objects during the mapping process (and is a lot easier than editing the JSON).
I have been struggling to get fetched properties working correctly in my app and have been finding it extremely confusing - mainly due to this strange issue I have finally figured out!
Basically if I change the Predicate on a Fetched Property in my xcdatamodeld and then Build-Run the app ignores this new Predicate and continue to used the old Predicate.
Hard to describe how absolutely annoying and frustrating this is, but am sure I am not the first to encounter this.
Any idea's on how I can force this to update the changes with each rebuild?
Ok so according to Apple's Core Data versioning guidelines, two versions are treated as being identifical if:
For each entity the following attributes must be equal: name, parent, isAbstract, and properties. className, userInfo, and validation predicates are not compared.
For each property in each entity, the following attributes must be equal: name, isOptional, isTransient, isReadOnly, for attributes attributeType, and for relationships destinationEntity, minCount, maxCount, deleteRule, and inverseRelationship.
So looks like changing a fetched property's predicate doesn't qualify as a 'change' ... how wonderfully confusing.
You can force it to consider the model 'changed' by changing the value of the Core Data Model Identifier
There is one requirement to create a default attribute say 'Test' on creation of an entity like we have Owner field common in every entity in CRM 2011. Can you please help me in this?
The easiest codeless solution is to have a workflow fire on create of your record. The value won't appear straight away but it will always be set.
There is no supported way to allow automatic creation of a new metadata attribute on an entity, that is triggered by the creation of the entity itself (it is not possible to register a plugin against the creation of an entity). My recommendation is that given the (surely) rare incidence of entity creation, remember to add the custom attribute yourself. This will undoubtedly take you less time than trying to hack an automated workaround.
Edit:
I still stand by disuading you to do this in an automated way, however as a trigger point you might consider harnessing the publish or publishall message as a way to fire a custom plug-in (as per my note below).
I search with reflector and I didn't manage to find a case where the ValidationResult.MemberNames is supposed to contain more than one value.
So, first of all I am wondering why MS had to do it IEnumerable<string>, then now that they already did this, can I rely that this property will only return one value?
Update
Concerning the DataAnnotations validation system I find more sloppiness:
The TryValidateProperty and TryValidateObject should have removed the errors from the validationResults parameter if they don't exist any more.
ValidationResult should have overriden Equals and GetHashCode.
Why is the ValidationResult.ErrorMessage mutable!? I can't event build an EqualityComparer myself!
If the DataTypeAttribute is only used for representation concerns, why does it inherit ValidationAttribute, that's just misleading, I had to struggle till I understood (after reflectoring) that its not going to work. MS just didn't implement it.
And the list goes on.
Consider Password and PasswordConfirmation. Or any Start/Stop values, or any other cross-field validation.