I have no idea now as to how to fix this random cypress failure [component-operation.cy.js] though i reran this test but it still fails and passes locally as shown in the screenshot.
So right now there are 3 cypress tests failing and i have no idea why these tests are failing. No idea how i can move forward in fixing those. The major problem i have in setting up my cypress test is the XbSetup is throwing error.
Though looking for a way forward on this.
This is now good for review. The failing pipeline in cypress test is not part of the changes done in this MR.
The pipeline passed - https://git.drupalcode.org/issue/experience_builder-3516432/-/pipelines/..., when the work was done. but failed after a rebase done from another person and i may know why because of the major changes introduced in ApiLayoutController.
I'll update the test case for this once.
but the actual update in gitlab file goes to this issue - https://www.drupal.org/project/experience_builder/issues/3518292 ✨ Allow searching for content in the editor navigation Active , where pipeline failing for 1 and passes for another , i'll update the gitlab file for that. Thanks
Adding screenshot for single and multiple asset. I do see it just gives around 7-8 assets in result but takes around 2 sec which is still higher in number
deepakkm → created an issue.
MR !957 was messed and hence created a new MR with similar changes
deepakkm → changed the visibility of the branch 0.x to hidden.
Agree to it that this should be under a feature but not as bug. As it was never worked upon earlier.
deepakkm → created an issue.
Yes the result count should be 0 in this scenario thats what i meant by saying "However, when we search for 'Untitled Page,' we only get one result, which should not be the case."
The failing pipeline is due to the rebase done with 0.x otherwise all tests are passing.
created to separate ticket to cover autocomplete feature - https://www.drupal.org/project/experience_builder/issues/3522488 🐛 Entity saved with autosaved data is not respected Active
deepakkm → created an issue.
I think its good to go now. Hence moving it in review.
deepakkm → made their first commit to this issue’s fork.
All the threads are resolved hence moving into review.
deepakkm → made their first commit to this issue’s fork.
Looks good
ankitv18 → credited deepakkm → .
deepakkm → created an issue.
deepakkm → made their first commit to this issue’s fork.
Hello @japerry - we have validated all scenarios and we are good to go with this changes and we are actually catching all the exception and hence i don't think we would require those additional handling of errors. I believe throwing only dam exception should be good to go.
deepakkm → made their first commit to this issue’s fork.
deepakkm → created an issue.
deepakkm → created an issue.
deepakkm → made their first commit to this issue’s fork.
Pipeline is now passing, hence moving ahead for review.
deepakkm → made their first commit to this issue’s fork.
@japerry - do you suggest we create the default view mode on hook_ENTITY_TYPE_insert()?
deepakkm → made their first commit to this issue’s fork.
deepakkm → made their first commit to this issue’s fork.
deepakkm → made their first commit to this issue’s fork.
deepakkm → changed the visibility of the branch 3508635-entity-browser-to-media-library to hidden.
deepakkm → made their first commit to this issue’s fork.
Pipeline is now green, hence moving in review.
I think due to the rebase the changes were lost from gitlab CI file, may be the rebase was incorrect.
Changes looks good to me and verified locally too, hence RTBC'ed
deepakkm → made their first commit to this issue’s fork.
deepakkm → made their first commit to this issue’s fork.
deepakkm → made their first commit to this issue’s fork.
Kindly review MR !118
deepakkm → changed the visibility of the branch 3501895-bulk-import-existing to hidden.
deepakkm → changed the visibility of the branch 3501895-bulk-import-existing to hidden.
deepakkm → made their first commit to this issue’s fork.
this has been taken care in the latest commit as we have handled the situation on the basis of media source now.
If you attempt to create a new media type from Acquia DAM with source Acquia DAM: Video and named "DAM Remote Video" with the machine name "dam_remote_video" it fail to work as expected. This is because the bundle name doesn't align with the predefined one, "acquia_dam_video_asset".
This issue doesn't replicate on branch 1.0.x, if you read the description of the issue this was working until 1.1.0-rc1 but due to certain commit it started failing and hence this was fixed for 1.1.x branch.
Since this is merged can someone close this ticket
deepakkm → created an issue.
deepakkm → created an issue.
verified changes hence RTBC
deepakkm → changed the visibility of the branch 3500257-no-revision to hidden.
deepakkm → created an issue.
deepakkm → created an issue.
deepakkm → made their first commit to this issue’s fork.
deepakkm → created an issue.
ankitv18 → credited deepakkm → .
ankitv18 → credited deepakkm → .
ankitv18 → credited deepakkm → .
rajeshreeputra → credited deepakkm → .
rajeshreeputra → credited deepakkm → .
deepakkm → made their first commit to this issue’s fork.
rajeshreeputra → credited deepakkm → .
rajeshreeputra → credited deepakkm → .