“ If debugging is the process of removing software bugs, then programming must be the process of putting them in. ” – Edsger Dijkstra
Dynamics 365 is a place where only dirty entities and fields are saved! The clean fields are ignored #HoskCodeWisdom
- Junior developer – assumes how things work
- Good developer – finds out through trial and error
- Great developer – does not assume and methodically confirms
Dynamics 365 can frustrate developers (The Frustrations of a CRM Developer), developers are provoked by the idiosyncratics, limitations and bonkersness of Dynamics 365 as Microsoft works on new ways to annoy developers 🙂
Bugs and problems areopportunities to gain a deeper knowledge of the workings of Dynamics 365.
New developers get caught out such as in the CRM 2011 (good old) when SetSubmitMode was a rite of passage for Dynamics CRM developers – CRM 2011/2013 – What does setSubmitMode do? and how does it work?
Unless you made the field dirty and change SubmitMode the field was not sent to the database to be saved
Try, Try and try again
On creation of an appointment the start and end times should be editable, on a form update those fields should be readonly.
Examples of using the SetDisabled(true) were found in the code, copied and adapted for the start and end times on the appointment entity.
Insanity: doing the same thing over and over again and expecting different results. Albert Einstein
Developer Insanity: Testing the same code over and over and expecting intermittent result #HoskCodeWisdom
Hosk developer debugging beliefs
- Investigate bugs with an empty mind
- Microsoft 365 is full of quirks which make sharing knowledge between team members important
- Bugs are not a sign of a bad developer, they are a sign of a developer developing #HoskCodeWisdom
- Always help your fellow developers, big projects need a strong team. Never leave a developer stranded
- Don’t suffer in silence if you are not making progress, get help and get direction #HoskWisdom
SetDisabled = true
The way to make a read-only field editable is to use the Dynamics 365 JavaScript Xrm, get the control and use the setDisabled(false)
Xrm.Page.ui.controls.get(“your field name”).setDisabled (true); //Field readonly you can’t write any thing on field
if you change true as false;
Xrm.Page.ui.controls.get(“your field name”).setDisabled (false); //Anyone can put value on this field
I looked at the code, it looked fine, we checked a few things
- Is there any other code changing the field back to read only –> No
- Checked the line worked in the debugging console –> Yes
- Was there a JavaScript error –> No
- Debug the code, does it run the line of code which enables the field –> Yes
Appointment entity
In this example we used the appointment entity, which is an odd entity. It‘s not possible to add new forms for the appointment entity Dynamics 365 – You can’t add new forms to the appointment entity There is code running on the appointment entity which a CRM developer has no control over, cannot see and cannot edit.
When you book appointment it sets the user who booked the appointment as the organizer of the appointment. This is fine for Outlook but not what I wanted to happen in Dynamics 365.
Adding hidden custom code which developers can’t disable is frustrating as much as it is undocumented, I believe Microsoft should write customizations in the same way standard Dynamics 365 developers do. This would allow us to see, modify, disable or extend the default behavior.
Stop, think
When you rule out the obvious, it’s time to check the stupid – #HoskWisdom
Appointment entities don’t allow you to add new forms (or change the status/status reason of the appointment) because we couldn’t add new forms, we had JavaScript which when the regarding field was set to a specific custom entity we disabled the default section and showed a new section with custom fields on.
Usually a developer would create another form but we couldn’t because it was the appointment entity
This resulted in the same fields being on the form twice, the start and end times. So the code was working, except it was making the fields on the hidden section and the first fields on the form.
To resolve the problem go to the section (in code) and then retrieve the field you want and then make it make it editable.
Hosk values with bug fixing
- Developers who fix a problem which doesn’t keep popping back because it‘s not properly fixed
- Developers who use a bug as an opportunity to learn how Dynamics 365 works
- Developers should try to resolve the problem first before asking for help
- Don’t spend too long being puzzled by a bug before asking for help, Dynamics 365 has odd quirks and limitations which can take hours to resolve. Get direction from a colleague after 1 hour of frustration
- Developers should not assume, they must clarify (I wasted hours looking in the wrong place because I didn’t check my assumptions)
On a separate note but relatedish – Developers using JavaScript onload should be careful when setting and changing values because it can frustrate user by asking them to save a form when they haven’t change any values When to automatically change fields using Javascript
picture from here