astubenbord / paperless-mobile

An (almost) fully fledged mobile paperless client.
GNU General Public License v3.0
621 stars 32 forks source link

[Bug]: Views (pulled from Server) are not correctly filtered. #373

Open n1njaznutz opened 6 months ago

n1njaznutz commented 6 months ago

What happened?

Added two docs via server. Added two views and two correspondents in server and added 1 doc to each correspondent and each view is filtered to each of the correspondents.

When the Views are pulled down to the App, both docs appear in each View.

Steps to reproduce

See above

Log output from the app

No response

Screenshots

Screenshot_20240119_174814~2 Screenshot_20240119_174755~2

Paperless-ng*x Version

2.4.0

Paperless-Mobile Version

3.2.1+405

Device

Samsung Galaxy S23 FE

Operating System Version

Android 14

Device Locale

UK

Selected Locale

English (UK)

Additional Context

No response

DennisBaerlin commented 6 months ago

Yes, I have the same problem. I installed the app for the first time today and my views on start page are not filtered correctly.

Furthermore the views section of the app menu is empty. Not sure if this might be intended as a separate views configuration from server?

n1njaznutz commented 6 months ago

Yes, I have the same problem. I installed the app for the first time today and my views on start page are not filtered correctly.

Furthermore the views section of the app menu is empty. Not sure if this might be intended as a separate views configuration from server?

Yes, when I click on one of the Views (note tick next to view name) in the Documents tab, the two documents don't filter.

Screenshot_20240120_085731~2.jpg

astubenbord commented 6 months ago

I just checked and this has a simple reason: Paperless 2.x.x (not sure from which version this started exactly) now allows to filter for multiple correspondents which creates a new filter rule identifier (26, any correspondent in list) vs. the previously used identifier for exclusive selections (3, has correspondent). I'm currently just not able to keep up with the progress being made on paperless-ngx.

On a side note: Going into the future, I'll probably have to drop support for older versions. If someone decides to stick with a specific version, that's fine, but then they'll either have to use an older version of the app or use the web interface. I'll try to add which paperless version a specific app version was tested on (for future releases), but that'll require several instances of paperless and automated tests, which is also not really feasible for me at the moment. In addition, the app has just grown too complex and has collected a lot of technical debt over the last months, which will require another refactoring in the near future in order to keep developing new features as lean as possible. If you have ideas on how handling different api versions could be improved, feel free to reach out and discuss with me.

astubenbord commented 5 months ago

Also: Related to #304

n1njaznutz commented 5 months ago

I just checked and this has a simple reason: Paperless 2.x.x (not sure from which version this started exactly) now allows to filter for multiple correspondents which creates a new filter rule identifier (26, any correspondent in list) vs. the previously used identifier for exclusive selections (3, has correspondent). I'm currently just not able to keep up with the progress being made on paperless-ngx.

On a side note: Going into the future, I'll probably have to drop support for older versions. If someone decides to stick with a specific version, that's fine, but then they'll either have to use an older version of the app or use the web interface. I'll try to add which paperless version a specific app version was tested on (for future releases), but that'll require several instances of paperless and automated tests, which is also not really feasible for me at the moment. In addition, the app has just grown too complex and has collected a lot of technical debt over the last months, which will require another refactoring in the near future in order to keep developing new features as lean as possible. If you have ideas on how handling different api versions could be improved, feel free to reach out and discuss with me.

Thanks for clarifying. Much appreciated.

Sunsurfer89 commented 5 months ago

On a side note: Going into the future, I'll probably have to drop support for older versions. If someone decides to stick with a specific version, that's fine, but then they'll either have to use an older version of the app or use the web interface. I'll try to add which paperless version a specific app version was tested on (for future releases), but that'll require several instances of paperless and automated tests, which is also not really feasible for me at the moment. In addition, the app has just grown too complex and has collected a lot of technical debt over the last months, which will require another refactoring in the near future in order to keep developing new features as lean as possible. If you have ideas on how handling different api versions could be improved, feel free to reach out and discuss with me.

Hey @astubenbord

I have the same issue as described by the other users (surprisingly also Samsung S23FE), but this is not the reason for answering.

You asked for an idea of how to deal with different API versions. I haven't had a look into the code because I'm just starting with Paperless NGX those days... But what about pushing the API version while connecting to the relevant server in the first response? Sure: the app code becomes more heavy because of case distinctions here and there if you have version dependencies, but as an interim solution, it might be the easiest way to deal with it. In the long term, you may need to add a disclaimer in the app and finally a blocking/warning if the API version is too old to force the users to upgrade Paperless on their servers...

I'm not sure if this is an acceptable approach... at least an idea. 🙃