forked from SFDO-Tooling/CumulusCI
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Snapshot Tasks to D2X's cumulusci-next Docker Image for Use Before Release in CumulusCI #12
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…FDO-Tooling#3799) Files uploaded via the app launcher in the orgs are currently not included in the metadata listings. To address this, the "display_files" task has been introduced to list these files efficiently. - This task gives the list of files in a tabular format querying the `ContentDocument`, fetching the fields Id, Filetype, and Filename, as filenames alone are not unique identifiers. - Upon uploading a new file, a fresh entry is generated in the `ContentDocument` entity, establishing it as the latest version in the `ContentVersion` entity. Subsequent uploads of new versions of already tracked documents are noted in the ContentVersion entity, without creating additional ContentDocument records. - Retrieving the latest version involves filtering the ContentVersion entity by setting IsLatest to true and employing the file's ContentDocumentId as the filter criterion.
…ither developerName or the PermissionSetLicenseKey (SFDO-Tooling#3798) To handle the compatibility issues and ensure smooth functionality for both `get_available_permission_set_licenses` and `assign_permission_set_licenses`, you can make the following adjustments: 1. **Revert `get_available_permission_set_licenses` to Return `PermissionSetLicenseKey`:** - This will maintain backward compatibility. 2. **Update `assign_permission_set_licenses` to Accept Both `DeveloperName` and `PermissionSetLicenseKey`:** - Modify the function to handle input as either `DeveloperName` or `PermissionSetLicenseKey`, ensuring it can correctly interpret and process both formats. This adjustment will resolve issues with names like `alpha.beta` where the `DeveloperName` is `alpha_beta`. Accepts api_name as `alpha_beta` or `alpha.beta` and assigns them correctly --------- Co-authored-by: James Estevez <jestevez@salesforce.com>
We missed the [announcement]: > Customers will then no longer be able to use multiple labels or target > non-name labels on larger runners after the 17th of June. [announcement]: https://github.blog/changelog/2024-05-16-new-dates-for-actions-larger-runner-multi-label-deprecation/
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: James Estevez <jestevez@salesforce.com>
…_and_retrieve_files Add tasks to extract and upload files (Salesforce Files)
SFDO-Tooling#3807) To ensure field-level permissions and successful dataset load, there are several validations performed on the `mapping.yml` file. These validations check whether the fields and SObjects have the required permissions, and whether namespaces need to be injected, as well as handling case insensitivity for the `mapping.yml`. This functionality is already implemented in the function `validate_and_inject_mapping`. However, there was a missing corner case where the function did not capture errors for required fields missing in the mapping.yml. This functionality has now been added, and the function is used for the preflight check. --------- Co-authored-by: James Estevez <jestevez@salesforce.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: James Estevez <jestevez@salesforce.com>
Suppress the required field check for the upsert action at mappingstep --------- Co-authored-by: aditya-balachander <aditya.balachander@salesforce.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…ies Task from Entries Option with Backward Compatibility (SFDO-Tooling#3820) ``` task: add_standard_value_set_entries options: api_names: CaseOrigin entries: - fullName: New Account label: New Account - fullName: Questionable Contact label: Questionable Contact ui_options: name: Add values to Case Origin picklist ``` For the add_standard_value_set_entries task, we noticed that only the fullname and label keys were being considered when generating the XML file for deployment, while other keys were being ignored. We've implemented a fix to ensure that all provided keys are now included in the standard value entry XML file. For example , If the entries were given like this , ``` entries: - fullName: testerunner label: testrunner groupingString: Scheduled ``` Now, it generates an XML like this ``` <standardValue> <fullName>testerunner</fullName> <label>testrunner</label> <default>false</default> <groupingString>Scheduled</groupingString> </standardValue> ``` But, there were case by case scenarios added for "OpportunityStage","CaseStatus","LeadStatus" which were left untouched to maintain backward compatibility and default will be always set as False, even though we pass in the entries as true. Related work item : [W-16541459](https://gus.lightning.force.com/lightning/r/ADM_Work__c/a07EE00001zQu1TYAS/view)
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Bharath Chadarajupalli <vchadarajupalli@salesforce.com>
…gs (SFDO-Tooling#3822) Update `form_handlers.py` to reflect changes to Salesforce's html tags for checkboxes and form inputs. The new tags changed from `lightning-input` to `lightning-primitve-input-checkbox` and `lightning-primitive-input-simple`. Fixes SFDO-Tooling#3657
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: James Estevez <jestevez@salesforce.com>
…Snapshot object in the DevHub
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.