[Dxspider-support] Enabling Q:1 spots

[rin JG1VGX]

Dirk-san,
Thanks for your input!

> A better way would be to add the following line to your system startup file:
> set/var $RBN::minqual = 1
> A sysop user can use this command at any time to change it at run time.
> Note: it is a global parameter which affects every one using the node.

This worked a treat.
One problem has been solved!

> - 'user_default' This does the job, but cannot be overridden by users' own filters. Not useful?
>
> This is news to me. The thing about user_default is that it applies *only until* a user defines a personal filter for a category, it then will override the user_default with their preferences. The only caveat is that there seems to be a bug (in all branches) where "frequently" the user filter does not "take" until the user logs out and then in again.

Thanks for the clarification. I've been testing without logout/ins. It
certainly helped.
But as you explained, personal and user_default filters work in
exclusive ways. I kind-of expected they work in combination, eg.
user's filters on top of user_default filters (ie. sequential in the
filter ladder), which is not.

Another confusion comes from the fact that 'spots' filters work for
both regular and RBN spots unless any 'rbn' category filter is
defined.

Example:
- With no user_default filter defined, a user with only "acc/spot
by_dxcc ja" filter sees both regular and RBN spots only from JA.
- Then if sysop defines such as "acc/rbn user_default info {q:[2-9]}"
without user's notice, the user then sees 1) regular spots from only
JA, plus 2) RBN spots from worldwide.
- This is because, although user_default filter is overridden by
user's personal filter and becomes ineffective, since 'rbn' category
filter is now defined, the user needs a separate category filter
"acc/rbn by_dxcc ja" as well to get the same result.
- A safer approach here would be for the sysop to use a rather strange
"acc/spots user_default info {q:[2-9]}" filter instead of 'acc/rbn'.
This won't affect users' filter results like above.

I will split my reply here because it already is too long.


On Wed, Jul 7, 2021 at 5:08 AM Dirk Koopman via Dxspider-support
<dxspider-support at tobit.co.uk> wrote:
>
> On 06/07/2021 04:54, rin JG1VGX via Dxspider-support wrote:
>
> Hi All,
>
> I have played with filters myself and here is a summary.
>
> What I wished to do:
> - Allow Q:1 spots system-wide
> - Set Q:2-9 as default for a new user
> - Users can allow Q:1 as necessary
>
> What I have done:
> - set $minqual = 1 as Andy G4PIQ has suggested
> (But this cannot be a permanent solution because /local/RBN.pm needs to be updated manually each time /perl/RBN.pm is updated)
> - then played with various user filters, eg. acc/rbn, rej/rbn, user_default, node_default
>
> What I have found:
> - 'node_default' This looks like a different animal and serves no purpose in this case?
> - 'user_default' This does the job, but cannot be overriden by users' own filters. Not useful?
>
>
> This is news to me. The thing about user_default is that is applies *only until* a user defines a personal filter for a category, it then will override the user_default with their preferences. The only caveat is that there seems to be a bug (in all branches) where "frequently" the user filter does not "take" until the user logs out and then in again.
>
> "Frequently" in this context means: "never - when I am trying to find the fault" or "often enough for users to get confused and annoyed so that they logout, fume, wait a day or two and then login again when it now (magically) works".
>
>
> - finally got the gist that a single 'acc/ A' and a 'rej/ not A' mean the same, but multiple 'acc' filters works like additive (A OR B) while 'rej' works like multiplicative (A AND B).
> - if no /rbn filter is defined, /spots filters apply for both regular and RBN spots. But once any /rbn filter is defined, filters must be defined separately for both regular and RBN spots.
>
>
> Please do "help filter" or read it on the wiki. It's meant to be "intuitive", but then it would be - to me. It's not quite as you describe it. But in essence it's this:
>
>
> 0. If there is no filter for this "thing" then nothing is filtered. It is just passed on.
> 1. For every type of thing you can filter (spots, announcements etc) there as 10 filter slots.
> 2. You can have a different filter in each slot.
> 3. Each slot is tried in the order 0 -> 9. This is "ladder logic".
> 4. Empty slots are ignored.
> 5. For every slot that matches: if it is a REJ filter it immediately rejects that "thing"; if is an ACC filter it will accept that "thing". No further processing on that "thing" occurs for that filter.
> 6. REJ filters are tried first; if it falls out of the bottom then the ACC filters are tried and if it falls out of the bottom then that "thing" is rejected.
>
> The point of this is that nobody gets negative logic right the first time (nor the second or third time) however good one might be. Hence the REJ filters - they throw away everything you DON'T want. The ACC filters (only) give you what you DO want. You are therefore using positive logic to get what you want (much more of the time).
>
> As we are all consenting sysops here, you should be made aware of the implications of input filters on your feeds (or node_default file for that "thing"). Any input filter will affect what gets into your node for onward processing. It is dumped at source. BTW a more efficient way of reducing what your users can see is to rcmd/<node partner> acc/spots by_zone 1,2,3 (for instance) and your node will never see any spots from spotters in other zones. Saves a lot some bandwidth.
>
> So far my purpose was not fulfilled but currently I have at my node:
> - Set $minqual = 1
> - In case users bothered by busted Q:1 spots, I would suggest them to use
>   acc/rbn info {q:[2-9]}, or rej/rbn info {q:1}
>
>
> I agree with this. But it is not a perfect answer to the problem. At the moment, I don't know what the processing issues might be for "per user" $minqual settings.
>
>
> If there are better solutions, please let me know!
>
> 73 rin JG1VGX
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support



-- 
73 rin JG1VGX