Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
I have created an entity form for a serviceappointment that should allow users to update and save the information in the fields.
While the form for the correct record displays (using the id parameter for the source record), all of the fields are showing as read-only and the 'Submit' button is not showing. There are a mix of dropdowns and text fields, but none are changeable.
(to be really specific, if you examine the HTML the input control has `disabled="disabled"` set in its attributes, though I would expect this is being controlled by the entityform. If you delete the attribute in the developer console you're able to see the options in the dropdowns)
I have created writeable entityforms for other entities before so I know what I'm doing, but am a bit stumped as to why my form is not allowing users to change the information in this case.
do you have any other Entity Form for the same entity that is read-only?
if yes.. did you make sure your "content (non-root)" Web Page is pointing to the correct Entity Form?
Yes quite certain. I also tried it with a very simple version of the form (one field) but same results.
I suspect that that particular entity (Service Activity) is treated this way for some reason,though can find it documented (though that's not surprising).
If someone has the time or inclination could they test on their own system?
Check if you are associating the correct entity permission to the right web role
I did a bit of digging and I think I've figured out what's going on.
In the code that renders an entity form (EntityForm.cs, github.com/.../EntityForm.cs), on line 579, it checks the status of the record. Even if you've got everything setup correctly, the code requires that the statecode of the record is '0' to allow editing, otherwise it reverts to read-only mode. In the case of a service appointment, generally they get set to "Scheduled", which means a statecode of 3. In my testing, once I set the service appointment back to "Open", which is the statecode of 0, my form became editable.
This is a poor assumption in the code - as we can see in this case, a statecode of 0 shouldn't necessarily be required to make it editable (although in most other cases, 0 means active, and 1 mean inactive).
The only advice I can offer is to make the service appointments "Open", and also to submit a bug ticket to Microsoft - as far as I'm concerned this is a bug.
Hope that helps.
great investigation Nicholas.. I would say perhaps nobody reported this bug to MS yet.. perhaps opening a ticket would be a good option
or raising an issue in GIT.. not sure MS is monitoring the community project though
Can confirm that that is correct, after I changed status from 'scheduled' to 'open' on a service activty record the form on the portal became writable with all of my other settings staying intact.
Here is the reference for the ServiceAppointment entity, which fails to describe the 'scheduled' (StateCode 3) status when saying "Completed and canceled service activities are read-only and can't be edited". https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/entities/serviceappointment#BKMK_StateCode
Good find! (so much for all of the time that I had sunk into creating a new entity to work with the form). To use it in this way will create problems for us as we are using the Status Reason values in a logical way so I will open a ticket with MS.
MS don't monitor the community project as it is for custom deployments of Portal code, but I have created the issue here github.com/.../117 - though there may be a problem with simply saying 'make statecode of 3 editable' in all cases, as described there.
Is the Entity setting "Read Only for Mobile" checked? This trips up everyone. Mobile tends to be more than mobile in the new UI.
Business Applications communities