Set topic tracking level via API call

[nephros]

Allows to switch topic tracking level from the context menu.

Not entirely sure about the UI, it fits in the context menu, but maybe it should be somehere else?

Anyway please comment whether something like this would be accepted.

Also, removes the "Don't Track" option without handling the local db changes that did. Are those still needed?

[nephros]

API docs: https://docs.discourse.org/#tag/Topics/operation/setNotificationLevel

[szopin]

Idea is great, was considering something like it, just not sure if this implementation won't break the logged out view, as notification_level is not provided then by the api, will check it tomorrow

[nephros]

Idea is great, was considering something like it, just not sure if this implementation won't break the logged out view, as notification_level is not provided then by the api, will check it tomorrow

Hm should be easy enough to check for logged in state.

Also, was thinking of putting both the display of tracking state, and the switching UI in into PostView, either in the PullUp menu, or somewhere below the header. That way it would be more contained, and completely hidden when logged out.

OTOH it's less convenient.

Another variant would be just one Context Menu entry ("Change Tracking"), and a separate dialog page for changing. That would probably also solve the refresh problem after changing.

[szopin]

Probably just setting it to -1 as default will be enough.

refresh problem Should be fine with just model.setProperty on succesful xhr

On Thursday, 22 August 2024, Peter G. wrote:

Idea is great, was considering something like it, just not sure if this implementation won't break the logged out view, as notification_level is not provided then by the api, will check it tomorrow

Hm should be easy enough to check for logged in state.

Also, was thinking of putting both the display of tracking state, and the switching UI in into PostView, either in the PullUp menu, or somewhere below the header. That way it would be more contained, and completely hidden when logged out.

OTOH it's less convenient.

Another variant would be just one Context Menu entry ("Change Tracking"), and a separate dialog page for changing. That would probably also solve the refresh problem after changing.

-- Reply to this email directly or view it on GitHub: https://github.com/szopin/harbour-sfos-forum-viewer/pull/73#issuecomment-2303912244 You are receiving this because you commented.

Message ID: @.***

-- Sent from my Jolla

[nephros]

Probably just setting it to -1 as default will be enough.

Working on that.

refresh problem Should be fine with just model.setProperty on succesful xhr

Tried that, but in my test the display (delegate) did not update properly. Will revisit this.

[szopin]

Not sure about removing the option to stop the native tracking (the highlight of previously opened posts), definitely for logged out users would make sense to leave in, not sure if it clashes with this mechanism, will play with it more tomorrow, but looks good

[nephros]

Maybe something like this is better UI

[szopin]

Buttons in my swipe-based UI??? jk, looks good and does prevent the menu-overgrowth which is plaguing the threadsview, btw not sure if we should display any icon for the normal state (also I find it weird I'm tracking a ton of threads just for giving someone a like, seems really... I don't even know, doesn't seem to have any effect, or maybe it's my notification settings)

[nephros]

I know, I know, disgusting Buttonses, we don't wants it, precious.

So, no star for 'Normal', non filled star for Tracked (the full one doesn't match with the other, dmpty ones). Bell instead of eye for 'Watching'.