Skip to content

[FEAT] Reject Adhoc Messages #227

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

afallenhope
Copy link
Contributor

@afallenhope afallenhope commented May 24, 2025

This PR is to address an annoyance where users automatically add you to a conference.
As a result, I've added the option to automatically leave the conference (adhoc), and announce (if requested).
Idea came from the very talented Firestorm folks so I appreciate their take on this. I've bound the event on llagent.

*Known Issues / Caveats
None that I'm aware of

@cinderblocks
Copy link
Collaborator

@PanteraPolnocy 's implementation is less complicated and functionally does the same thing. Why not just use that? I don't see the advantage in tying gAgent in when gIMMgr is also global.

Also, having two conflicting boolean settings can be enumerated under one setting. Off, Friends, All.

"Reports to nearby chat if a conference (ad-hoc) has been ignored." is also very Firestorm-specific wording for a system message. I don't see why it would logged to nearby chat when a session id exists either. Makes for messy chat logs.

@afallenhope
Copy link
Contributor Author

@PanteraPolnocy 's implementation is less complicated and functionally does the same thing. Why not just use that? I don't see the advantage in tying gAgent in when gIMMgr is also global.

Also, having two conflicting boolean settings can be enumerated under one setting. Off, Friends, All.

"Reports to nearby chat if a conference (ad-hoc) has been ignored." is also very Firestorm-specific wording for a system message. I don't see why it would logged to nearby chat when a session id exists either. Makes for messy chat logs.

Thanks @cinderblocks I appreciate the feedback.

  • I chose to use gAgent because I noticed the isDoNotDisturb setting is already tied to it, and it seemed to align well with the functionality was being implemented.

  • I also appreciate the idea of combining the two conflicting booleans into a single enumerated setting. The proposed values could be something like:

<combo_box
        control_name="AlchemyIgnoreAdHocSessions"
        follows="left|top"
        layout="topleft"
        height="23"
        name="adhoc_preference_combo"
        width="115">
    <item
        label="Off"
        name="adhoc_preference_allow_none"
        value="0"/>
   <item
        label="Friends Only"
        name="adhoc_preference_allow_friends"
        value="1"/>
    <item
        label="All"
        name="adhoc_preference_allow_all"
        value="2"/>
  </combo_box>

This would make it more flexible.
Changing from getBOOL to getS32.
UI wise, a checkbox instead of dropdowns was much easier (for myself).

I thank you again for the valued feedback.

@PanteraPolnocy
Copy link
Contributor

"Reports to nearby chat if a conference (ad-hoc) has been ignored." is also very Firestorm-specific wording for a system message. I don't see why it would logged to nearby chat when a session id exists either. Makes for messy chat logs.

This was implemented because some users would forget that ad-hoc sessions had been ignored, leading to confusion, so the message to nearby serves as a visible reminder.

@afallenhope
Copy link
Contributor Author

afallenhope commented May 25, 2025

"Reports to nearby chat if a conference (ad-hoc) has been ignored." is also very Firestorm-specific wording for a system message. I don't see why it would logged to nearby chat when a session id exists either. Makes for messy chat logs.

This was implemented because some users would forget that ad-hoc sessions had been ignored, leading to confusion, so the message to nearby serves as a visible reminder.

Personally I think it's a great reminder. Thank you for your great work on this.
I did take the suggestions that @cinderblocks has recommended.

  1. Removed it from llagent and strictly read it from the gSettingsPerAccount.getS32("AlchemyIgnoreAdHocSessions")
  2. Changed to a combobox which does look nicer instead of two checkboxes
    image
    image
    image

@cinderblocks
Copy link
Collaborator

"Reports to nearby chat if a conference (ad-hoc) has been ignored." is also very Firestorm-specific wording for a system message. I don't see why it would logged to nearby chat when a session id exists either. Makes for messy chat logs.

This was implemented because some users would forget that ad-hoc sessions had been ignored, leading to confusion, so the message to nearby serves as a visible reminder.

Yes, and justifiable in Firestorm because of the Phoenix/V1 influence of reporting lots of stuff to chat. Whereas in V3, system notifications are toasted. However, only mentioning it as the description is incorrect given that FSUtils::reportToNearbyChat() or whatever that function is called doesn't exist in Alchemy.

@cinderblocks
Copy link
Collaborator

  • I chose to use gAgent because I noticed the isDoNotDisturb setting is already tied to it, and it seemed to align well with the functionality was being implemented.

Understood, and I see you already made the change. Case could be made that DoNotDisturb and AutoRespond have no place in gAgent either as they are instant messaging states and not agent control states.

@afallenhope
Copy link
Contributor Author

I see you already made the change.

Yes, it was a great suggestion and I value the feeback.

Case could be made that DoNotDisturb and AutoRespond have no place in gAgent either as they are instant messaging states and not agent control states

I feel that would have to be in a separate PR as that would relate to a separate request.

I've also took the suggestion of using LLNotificationsUtil to display the notification. Thank you for the valued feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants