Closed ayya-vimala closed 1 month ago
Backend throws the following error:
File "/usr/local/lib/python3.7/site-packages/pyArango/query.py", line 157, in __init__
fastapi | raise AQLQueryError( message = e.message, query = self.query, errors = e.errors)
fastapi | pyArango.theExceptions.AQLQueryError: Error in:
fastapi | 1:
fastapi | 2: FOR category IN 1..1 OUTBOUND concat("menu_collections/", @collectionkey) GRAPH 'collections_categories'
fastapi | 3: RETURN category.category
fastapi | 4: .
fastapi | ->AQL: no value specified for declared bind parameter 'collectionkey' (while parsing). Errors: {'code': 400, 'error': True, 'errorMessage': "AQL: no value specified for declared bind parameter 'collectionkey' (while parsing)", 'errorNum': 1551}
Text view doesn't seem to get the limit filter info through to the backend. Text view also doesn't update when limit filter is defined. Table view recognizes collections, but not individual files.
I pushed changes that make it all work in the backend. But the frontend text view doesn't provide the limit collection details. F.i. I give in a limit collection 'mn' but get this:
file_name='dn4' active_segment='none' score=0 par_length=0 limits=Limits(category_include=[], category_exclude=[], file_include=[], file_exclude=[]) multi_lingual=['skt', 'pli', 'chn', 'tib']
@TrebuhD - can you have a look at this? It also gives "active_segment='none'" at all times. Question is if "active_segment" is the best option for scrolling to folios or are there more functions to this? For numbers view I used a different approach to go to another folio.
As far as I can tell the only remaining frontend issue on this after recent update, is that the parallels column wasn't updating when the filters were changed, so that items that had been filtered out were still showing in the parallels column. The PR I just opened resets the parallel column on filter change.
One additional bit of logic that would probably be good to add is to only reset if the selected id isn't in the updated matches. I'll have a look at that tomorrow.
I thought I had closed this issue some time ago ..?? This works just fine. I just checked. The only thing it doesn't do is update the matches in the middle column if there are 0. Reset on filter change is good.
I thought I had closed this issue some time ago ..??
Still open... :grin: I'm currently trying to clear out tickets, so please close any that you don't feel are relevant any more. Thanks :pray:
The only thing it doesn't do is update the matches in the middle column if there are 0.
It also leaves matches unavailable after applying filters. The PR does a crude reset to clear these on filter change; unfortunately, at the moment, I don't think there is enough data to persist matches that still apply.
This seems to work.
Exclude/include filters don't seem to work correct at all times. It seems to give back the wrong results most of the time.
It also shows 0 matches while there are clearly a lot of matches