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

Personal landing page #163

Closed
alexhebing opened this issue Nov 13, 2019 · 5 comments · Fixed by #501
Closed

Personal landing page #163

alexhebing opened this issue Nov 13, 2019 · 5 comments · Fixed by #501
Labels
good first issue Good for newcomers specification Precise specifications given
Milestone

Comments

@alexhebing
Copy link
Contributor

alexhebing commented Nov 13, 2019

A view that is the personal landing page for a user, i.e. the page they land on after logging in. This should be a tab next to the search, explorer and upload tabs, possibly named "my READ-IT" or something like that.

At the very least, this page should contain three lists, with each item in each list being a hyperlink to its corresponding panel in the explorer:

At a later stage this page could also contain some statistics about the work a user did, e.g. number of annotations, how many sources added, how many sources worked on, etc.

This should be implemented as a CompositeView with a separate subview for each list (as well as for each other element that may be added in the future). The lists should have a common implementation, which may derive from, or have a common base with, the search results view. The elements of each list should be the existing search result item views.

Depends on #62.

@alexhebing alexhebing added the specification Precise specifications given label Nov 13, 2019
@alexhebing alexhebing added this to the Public accessibility milestone Nov 13, 2019
@jgonggrijp jgonggrijp added the good first issue Good for newcomers label May 6, 2020
@jgonggrijp jgonggrijp modified the milestones: Next presentation, Next presentation removals Jul 14, 2020
@jgonggrijp
Copy link
Member

Updated the specification a bit. The old version suggested that the landing page should give users an overview of their available options, but the menu bar already does this.

This was referenced Jul 14, 2020
@jgonggrijp jgonggrijp modified the milestones: Next presentation removals, Next presentation, Must-haves Jul 21, 2020
@BeritJanssen
Copy link
Member

Might be combined to #449 .

@jgonggrijp
Copy link
Member

Might also include a list of (semantic) queries. See reference above. Opening post updated accordingly.

@BeritJanssen
Copy link
Member

I think we should move the list of previous queries to "ideally" or "interesting ideas" - this means extra work, especially if we also want to be able to go back to previous full-text or mixed searches.

@jgonggrijp
Copy link
Member

I already installed an endpoint at the backend that lists all own queries by default, and we have CollectionView, so I think it should be relatively easy. That said, I can agree with leaving this out for the time being.

(As for text search, in principle that's just a matter of storing the query routes. But again, I agree with postponing such a feature.)

jgonggrijp added a commit that referenced this issue Nov 10, 2021
jgonggrijp added a commit that referenced this issue Nov 10, 2021
jgonggrijp added a commit that referenced this issue Nov 10, 2021
jgonggrijp added a commit that referenced this issue Nov 10, 2021


The remove: false option was added in c100042 in order to enable
paginated annotation fetching (#253). We however removed that feature
again in da75f42 (hotfix 0.11.1). It was not being used anywhere else
and now, it caused the userItems and userSources globals to wrongly
retain the user's items and sources after logout (and even across a
subsequent login) (#163). If we ever need to retain nodes on a
subsequent query again, we should instead opt to pass an aditional
options argument.
jgonggrijp added a commit that referenced this issue Jul 19, 2022
This radio endpoint was moved to another channel in 3160b1a as part
of #501, #163, #449 and #354, but FlatItem and its tests were not
updated accordingly. Since the tests were still using the old channel,
they did not detect the bug. Updating only the tests in this commit
reproduces the bug.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers specification Precise specifications given
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants