I'm trying to calculate a date field value based on another field, using the Business Rule feature in CRM 2013. The field is locked on the Form so that the user cannot modify. I think because of this setting, the field value is bet set initially however when I click the 'Save' button the value disappears.
I believe this is the same as setSubmitMode("always") issue for read-only fields. I am wondering if there is a way to resolve this issue inside the Business Rule or Form/Field settings ?
I'm having the same problem but I found this workaround:
The workaround is to add the locked field twice on the form. Make 1
instance of the field 'read only' and 'visible' and then make the 2nd
instance of the field NOT 'read only' and NOT 'visible' on the form.
then when the Business Rules fire it will see that one of the
instances of the field is not read only and then save to the database.
Source:
https://social.microsoft.com/Forums/en-US/741916de-e637-40f1-a675-944e7c0f5130/crm-2013-business-rules-updating-read-only-fields?forum=crm
Related
On oracle applications R12 I am trying to set a field as required. I have it set as required but it is not behaving as I wish. If you are creating a new form or if you are editing an old form and blank out the required field, it will tell you that you need to fill it in, which works as expected. If there is an old form that has a field that someone previously forgot to fill in, before it was required, it does not make you fill in the field. Is there any way for the required field to trigger when someone goes to press save? Thanks!
You can trigger the validation of that field by updating it's value to itself in order to set the record status to CHANGED, for example in the post-query trigger :block.item:=:block.item;
Alternatively, you can use the validate built-in
I am trying to add a field to my entity call abc_salespersonname when I try to add it I am presented with duplicate field name.
The field does not show in the solutions entity field list but I can see it in the database.
I do know that when you delete a field from an entity, it does not actually delete from the database.
So my question is, how can I bring this field in the database back onto the entity.
You cannot Undelete any field in a supported way. Once deleted is deleted, gone forever.
Not sure, if you are mixed up with “Remove” & “Delete” options within solution sub-components. Atleast “Publish All Customizations” will make all the database schema, Metadata & UI in sync. Verify the default solution by going to Settings->Customizations->Customize the system to double check.
If you are seeing duplicate field name alert, then you cannot bypass it. Create a new field with different name & move forward.
My Account entity has an Account Manager field. I would like to add this same field to Opportunity as a reference. Is there a way to add this field to Opportunity and make it point to the attribute "Account.Account Manager"?
I am using MS Dynamics CRM 4
What you're asking for is copying the field "Account Manager" in entity "Account" to entity "Opportunity", is it?
If that is what you want, you need to create a field named "Account Manager" (or whatever you wish to) in the "Opportunity" entity form; the field type being the same. And you need to have some kind of workflow/plugin/javascript to update the field in "Opportunity" form with the same value as present in the "Account" form.
EDIT: Based on your comment, I've edited the answer. You can achieve it by two means:
Have some kind of workflow/plugin populating the field in
Opportunity form from that of the Account form.
Fetch the value of the Account field by javascript on Opportunity
form load and display it in a field.
Also, you might want to make the field read-only in Opportunity form.
I have a Master Detail form in my Oracle APEX application. When I am trying to update data in this form, I am getting below error.
Current version of data in database has changed since user initiated
update process. current row version identifier =
"26D0923D8A5144D6F483C2B9815D07D3" application row version identifier
= "1749BCD159359424E1EE00AC1C3E3FCB" (Row 1)
I have cleared browser cache and try to update. But it not worked.
How can I solve this?
I have experienced similar problem where my detail records set has timestamp fields. By default master detail wizard creates the timestamp fields as date picker type fields. If you set the date format on these, it would resolve the issue.
This blog post tries to address this issue on a Tabular Form (I know that's not what the original issue was with, but thought it might be related). It says the same as #sangam does below.
Short version: If you have an updated field that's timestamp datatype, you should set a date/time format.
http://apexbyg.blogspot.com/2015/05/tabular-form-bug.html
My tabular form has a field that's timestamp datatype, but I had already set a date format, so this didn't help me.
Here's another possibility, which I discovered was the case in my application.
That would be if the data the original checksum was calculated on is truly different than the pre-update checksum calculation, due to a design-flaw in your query!
In my application, the source for one of the updateable fields was COALESCE(name_calced, name_preferred). In the source table, the person's name could already be loaded in the record by an external process and we save it to one field - name_calced. But the end-user can enter a preferred name, which we wanted to save to the name_preferred field. We wanted to initially populate the displayed, updateable tabular form field with name_calced, if one existed, or name_preferred if the user had already provided a preferred name. Then they could change that value and save it back to the database.
I finally discovered that the Save action threw the error message if name_calced was non-null, but name_preferred was null. I realized that the initial checksum was calculated based on name_calced, but the pre-update checksum was based on name_preferred, so the application thought someone had changed the value in the background and showed the error message.
What I don't understand is how this problem didn't show up in the past 3 years the application has been running in production!
My solution is to make the field source only on name_preferred, which immediately solved this problem. I also think the back-end process will also get changed to pre-populate that table field from name_calced, so the user always sees the base value, if there is one.
I just had this issue myself. Now, I realize that tabular forms are deprecated at this time, but I have an application that was developed beforehand and still uses them. This issue occurred and I had to get one of our big guns at Oracle to help me out. I do a lot of DB work and a decent amount of Apex development but I'm more of a Java, WebLogic, etc guy, and I really couldn't figure this one out.
In my case, it turned out to be really simple. One of the columns in my tabular form was a hidden field, generated via a sub query. Being hidden, this column is not editable by the user and should not be part of the MRU update. I had the field set to "Hidden Column (saves states)" and setting its type to "Hidden Column" fixed the issue. So, this leads to sub queries being executed in such a way as to change the checksum for the overall query before hitting submit (save), causing the error.
For those who are continuing to troubleshoot this, look at your query for every field that you have specified and note which columns are editable in the tabular form. All other fields should be set in a way that makes them not save state so that they are not part of the update.
I had this error when I had two update processes processing on submit.
My solution was to add a condition to both processing steps. I had forgotten to do this when I made an additional process for Button A, but I never updated Button B to limit it's behaviors.
Navigation:
Processing -> Processes -> [Your Process Name] -> Server-side Condition -> When Button Pressed = [Your button Name]
In my case I had a column from a secondary table that was not set as Query Only and was being updated! The error would occur trying to save a column not in the table being updated. It took me half a day to figure it out (the column names were the same).
Set your Link column hidden to display only in the form.
Set "Send On Page Submit" to 'No' or disable the link column that is your primary key ( Rownum/rowid/id etc).
Hope it will work for you.
I have noticed this error comes when I was working Tabular Form and has disabled one of the form operations i.e. by setting server-side condition to "Never" for add, apply changes (submit) buttons
When I have restored back to its original state, it worked as expected.
In case you have to hide Add/Update button, use some other option.
https://compknowledgebase.blogspot.com/2018/12/oracle-apex-error-current-version-of.html
I have a MS CRM 4 form where when certain fields are changed, I need those fields to be written to an excel sheet.
So, I edited the form field onchange event to call crmform.save() which triggers a plugin to run that writes the field value to a named range (1 cell) of an excel sheet.
However, I don't know which field caused the save. Is there a way to get that information? (Not all fields on the form need to go to the excel sheet)
If I use this: DynamicEntity target = (DynamicEntity)Context.InputParameters[ParameterName.Target];
I can look at specific fields, but I have no way of knowing which ones changed.
Any suggestions?
It's my experience that only the changed fields will have value (in the DynamicEntity) when you update an entity. So let's say you have an entity with a FirstName and Lastname. If you only change the LastName and save. The LastName will have a value however FirstName with be null (unless you have som javascript code that forces the FirstName to be submitted).
If your plugin is triggered on the Pre-Event of the Update on your entity, you should be able to compare the IPluginExecutionContext.PreEntityImages to your DynamicEntity that you've fetched from the Target.
Or if your plugin is triggered on the Post-Event of the Update, you should be able to compare the IPluginExecutionContext.PreEntityImages with IPluginExecutionContext.PostEntityImages.
Looks like you are already going a different way, but another suggestion is to create a hidden field - "FieldThatChanged." In your field on-change javascript, set that field to the name of the field that changed, then access that in your plugin.
Yep, totally changed the way I approached this. I'm using jquery in an iframe to pass all the exact fields (name/value pairs) I want to a method of an ASPX file running in the ISV folder that takes the neccesary action. Thanks for the suggestions all!
I recommend using the Pre and Post Images as suggested by #Forgotten Semicolon. And in addition set the Filtering Attributes so the Plugin is triggered only on the change of the fields you care about.