You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is just a nugget of an idea for now, but I was reminded toward the end of drafting the changelog for 8.0.0 that we did indeed lay the foundations for making privileges / access levels integrate better with what the server advertises.
As Sopel continues to improve its handling of ISUPPORT, STATUSMSG, and other protocol features, I can foresee that there will be demand for more dynamic functionality. Some wild ideas that came to me:
Make available only the AccessLevel members that actually map to available prefixes the server advertises in ISUPPORT's PREFIX
Given a STATUSMSG prefix, look up which AccessLevel that corresponds to
Given a desired canonical access level, find out whether the server supports it
Specify fallback sequences for decorators such as @plugin.require_privilege() (e.g. require at least HALFOP if it's available, otherwise require OP or above)
I haven't looked at the protocol again just yet to see how feasible these might be, but all the same I wanted to get them out of my private notepad and into the issue tracker so they don't get lost—and so others can weigh in.
The text was updated successfully, but these errors were encountered:
This is just a nugget of an idea for now, but I was reminded toward the end of drafting the changelog for 8.0.0 that we did indeed lay the foundations for making privileges / access levels integrate better with what the server advertises.
As Sopel continues to improve its handling of
ISUPPORT
,STATUSMSG
, and other protocol features, I can foresee that there will be demand for more dynamic functionality. Some wild ideas that came to me:AccessLevel
members that actually map to available prefixes the server advertises inISUPPORT
'sPREFIX
AccessLevel
that corresponds to@plugin.require_privilege()
(e.g. require at leastHALFOP
if it's available, otherwise requireOP
or above)I haven't looked at the protocol again just yet to see how feasible these might be, but all the same I wanted to get them out of my private notepad and into the issue tracker so they don't get lost—and so others can weigh in.
The text was updated successfully, but these errors were encountered: