Select the Wireline record type when creating the new Job
Notice the Segment picklist. There are 3 selections in there and no default picklist value is auto-selected for the user.
In SFDC on the config side of things, that record type Wireline at the Job__c level has been configured to only show 2 picklist values with a default of Reservoir Evaluation. However in Mobile, the default picklist value isn't honored and the picklist is showing all 3 selections. We should make Mobile's picklist operate like the SFDC picklists operate with respect to default and filtering.
This card is related to #1839
Expected result
We never built in support to Mobile such that the default Picklist value is set based on the chosen record type. Several customers are asking for this functionality as they need it to simply and expedite data entry. In addition, supporting this functionality will bring our Mobile product into closer alignment with the way record types and picklist values operate in SFDC Back Office.
Analysis
The picklist default values per record type are not returned in the describe call but in the describe layout call (because record types define the layouts). Unfortunately we are not looking for this information here and throwing it away.
Note that the describeLayout results contains (what appears to be) a complete copy of the describe results for each field in the layout with any specific record type customizations to it.
Also note, that in addition to the default value changing per record type, the list of available values can also change per record type.
Options:
Retrieve the picklist default values from the describe layout call and include it with the layout info, then pass the layout into the model-factory when newing up an instance of an object.
Note that this will require updating the code in 4 places that use the model-factory (jobs, tickets, ticket items, eforms).
Another option would be to include the picklist default values from the describe layout call with the layout info (like above) and then structure the metadata so that it contains all possible default values. This could be done by passing the layout data into the Metadata constructor and parsing the data from within there.
Not sure what this structure would look like yet.
Note that this will require updating the sync steps.
Hmmmm, I think the only other option blows and would be do a describe layout (for all record types) for any picklist field returned in a describe call and then structure the metadata so that it contains all possible default values. Yeah, this blows, lets not go there...
UPDATE: After talking over with Craig, this really should be a story card in itself as it is a feature of record types that we have never supported and the extent of the implementation would be rather involved.
Based on the fact that the describe layout call contains a copy of the describe result (metadata) for each field, Craig thought it would be worth investigating whether we could eliminate the initial describe call altogether. I mentioned this to Yusuke and he think that is not possible as we need the full objects metadata to sync down all of the fields (mainly for calculations - any other reasons? references/lookups? search layouts?).
However, we could use the full metadata just for syncing down data and then only retrieve (from IndexedDb) the layout (w/ metadata included) for form rendering, etc. That would reduce the calls to the IndexedDb database as well as the filtering (field associating) between metadata and layout when building up a form, etc.
Additional thoughts:
Do we really need the full metadata to instantiate (via model-factory) an object or can we just use the metadata that's included in the layout? Are object level required fields included in the layouts?
Can we simplify the getDescribe method in sforce/index since we will be storing metadata in the layout as well?
Perhaps the main describe call would be needed only for building SOQL queries and building data contexts.
If we are storing the metadata inside with the layout, can we just pass the layout to model-factory? Probably not as there may be other fields not on the layout with default values.
Should pass the layout into the model-factory or make a separate call to apply layout/recType specific defaults. My thought is to pass it in as to avoid someone forgetting to call it if adding new code. Also I think we should probably pass in a specific layout because I don't think that we store all of our data in the same structure and the model-factory would have to know how to extract the layout by record type(?) for potentially differing structures. Since the code handling the call will have knowledge of it's object, it should know how to get it's layout.
UPDATE (2/6/2015): currently the REST API (I tested on both v29 and v32) does not support retrieving recordType specific info regarding picklists (neither recordtype specific picklist values or default picklist value per record type), both of which are pertinent to this card.
UPDATE (3/17/2015)
Apparently Salesforce provides the picklist value information for recordtypes as part of the layout results and not the actual describe results.
According to DP, we'll need to update the Layout sync process to pull the picklist information and store it as part of the layout in the store. Then we'll need to update the binding to read from the layout for the picklist values.
To see the picklist recordtype value information, you can use the Workbench, REST Explorer and do a describe on an object with a picklist with record type dependent values. Eg.
Then pick a record type, open the "url" folder and navigate to the url, click on "show raw response" and search for the string picklistValues" : [ {
Related Cards
Test Plan
How is this tested in Selenium?
Bob is writing the selenium tests (June 8)
Do we have adequate unit testing?
Model factory test cases updated to test this scenario
Where is this covered in documentation?
Had a discussion with andy about how this can affect customers that rely on defaults set via the picklist field on the object vs. those configured on the picklist field via record type layout
Where is this in Tarantula?
For now look at test plan (Test plan is on card #1839 as both are very similar)
githubbob42
commented
9 years ago
Mingle Card: 2460 Steps to reproduce
This card is related to #1839
Expected result
We never built in support to Mobile such that the default Picklist value is set based on the chosen record type. Several customers are asking for this functionality as they need it to simply and expedite data entry. In addition, supporting this functionality will bring our Mobile product into closer alignment with the way record types and picklist values operate in SFDC Back Office.
Analysis
The picklist default values per record type are not returned in the describe call but in the describe layout call (because record types define the layouts). Unfortunately we are not looking for this information here and throwing it away.
Note that the describeLayout results contains (what appears to be) a complete copy of the describe results for each field in the layout with any specific record type customizations to it.
Also note, that in addition to the default value changing per record type, the list of available values can also change per record type.
Options:
UPDATE: After talking over with Craig, this really should be a story card in itself as it is a feature of record types that we have never supported and the extent of the implementation would be rather involved.
Based on the fact that the describe layout call contains a copy of the describe result (metadata) for each field, Craig thought it would be worth investigating whether we could eliminate the initial describe call altogether. I mentioned this to Yusuke and he think that is not possible as we need the full objects metadata to sync down all of the fields (mainly for calculations - any other reasons? references/lookups? search layouts?).
However, we could use the full metadata just for syncing down data and then only retrieve (from IndexedDb) the layout (w/ metadata included) for form rendering, etc. That would reduce the calls to the IndexedDb database as well as the filtering (field associating) between metadata and layout when building up a form, etc.
Additional thoughts:
UPDATE (2/6/2015): currently the REST API (I tested on both v29 and v32) does not support retrieving recordType specific info regarding picklists (neither recordtype specific picklist values or default picklist value per record type), both of which are pertinent to this card.
UPDATE (3/17/2015)
Apparently Salesforce provides the picklist value information for recordtypes as part of the layout results and not the actual describe results.
According to DP, we'll need to update the Layout sync process to pull the picklist information and store it as part of the layout in the store. Then we'll need to update the binding to read from the layout for the picklist values.
To see the picklist recordtype value information, you can use the Workbench, REST Explorer and do a describe on an object with a picklist with record type dependent values. Eg.
/services/data/v32.0/sobjects/FX5__Ticket_Item__c/describe/layouts
Then pick a record type, open the "url" folder and navigate to the url, click on "show raw response" and search for the string picklistValues" : [ {
Related Cards
Test Plan
Bob is writing the selenium tests (June 8)
Model factory test cases updated to test this scenario
Had a discussion with andy about how this can affect customers that rely on defaults set via the picklist field on the object vs. those configured on the picklist field via record type layout
For now look at test plan (Test plan is on card #1839 as both are very similar)
Test Case: Filter picklist by record type