Skip to content
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

Batch selection is not in sync between search results and record view #8295

Open
tylerjmchugh opened this issue Aug 6, 2024 · 4 comments · May be fixed by #8492
Open

Batch selection is not in sync between search results and record view #8295

tylerjmchugh opened this issue Aug 6, 2024 · 4 comments · May be fixed by #8492

Comments

@tylerjmchugh
Copy link
Contributor

Describe the bug
The batch selection is not in sync between search results and record view. The UI should be updated on both when the selection is updated from one.

To Reproduce
Steps to reproduce the behavior:

  1. Submit a search
  2. Open the record view for one of the results
  3. Under "Manage record" select the "Add to the selection" checkbox
    image
  4. Return to the search results
  5. The selection is not updated on the search results page until the page is refreshed
    image

OR

  1. Submit a search
  2. Select the checkbox for one of the records.
    image
  3. Open the record view for that record
  4. Under "Manage record" the "Add to the selection" checkbox is always unselected regardless of the selection status set on the search page
    image

Expected behavior

After checking the "Add to the selection" checkbox from the record view and returning to the search results, the selection on the search results page should be updated without a page refresh.

AND

After adding the current record to the selection from the search results page, the "Add to the selection" checkbox state and label should display correctly within the record view.

Desktop (please complete the following information):

  • Browser: Edge
  • GeoNetwork Version: 4.4.6-snapshot
@josegar74
Copy link
Member

The problem is related to this default value metadata for the selection bucket, that is used in the metadata page when retrieving the metadata information:

@RequestParam(defaultValue = SelectionManager.SELECTION_METADATA)

public static final String SELECTION_METADATA = "metadata";

While in the search page, the metadata is added to the selection bucket named s101.

@fxprunayre what is the metadata bucket used for? I assume should be unified the value?

@fxprunayre
Copy link
Member

what is the metadata bucket used for? I assume should be unified the value?

Indeed, we should use the same bucket id to put elements in the same selection.

@tylerjmchugh
Copy link
Contributor Author

I tested implementing the solution of using s101 for both search and record view.

This seems to solve the issue of the checkbox being initially set incorrectly on the record view page. However, updating the checkbox value on the record view still does not update the search view after clicking "Back to search".

Is there an additional refresh that needs to be done upon clicking the "Back to search" button to persist these changes from record view to search?

@josegar74
Copy link
Member

josegar74 commented Aug 20, 2024

It seems executing:

$scope.closeRecord = function () {
gnMdView.removeLocationUuid();
};

That seems restoring the history and doesn't trigger the search. I'm not really sure yet that from that code we can trigger it as requires the SearchFormDirective, not available there.

The same problem happens when you delete a metadata in the metadata page (calls also the same closeRecord function), the search page is displayed including the deleted metadata.


I think the "Back to search" should trigger the last search, not using the history, to make sure it shows the latest results, not some old local cached stuff. But it's a bit unclear how to trigger a search when clicking that button.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants