feat(notifications): add toggle to show group chat start as incoming …

[hek4ek]

…call

• Added a new toggle in NotificationSettings to display group chat start notifications as incoming calls
• Updated notification handling logic to respect the new setting
• Added localization keys for the toggle label

Pull Request Checklist

• I read the contributing guide.
• Pull request contains a changelog label.

UI changes have been tested with:

• iPhone and iPad simulators in portrait and landscape orientations.
• Dark mode enabled and disabled.
• Various sizes of dynamic type.
• Voiceover enabled.

Signed-off-by: [email protected]

Enhancement for: element-hq/element-meta#2429

[CLAassistant]

All committers have signed the CLA.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[stefanceriu]

Hi 👋 Thank you for the contribution but we cannot accept user facing changes without checking with the product team first. There have been discussions around this but for the moment having Element Call not ring for rooms is the way to go.

Feel free to raise a ticked on https://github.com/element-hq/element-meta/issues and see if you can get any traction on it.

[alexander-potemkin]

@stefanceriu , it's quite an unexpected outcome, to be honest - the very same PR has been accepted by iOS team (@pixlwave to be more specific) earlier (here) and only rejected by Android team for one reason: Element 'Classic' was not accepting anything new at all.

I can't as well see any references to the necessity to get a prior approval on the Contribution Guide, nor in Pull Request guide.

I have, however, raised a separate issue as per your request: element-hq/element-meta#2802
How could a process of discussion with product team be held?

As per my understanding - and please, do correct me if I'm wrong or missing something, rings are an essential part of the group interaction, which is required for your biggest customers as well, unless you plan to keep that as a separate / paid feature of course?

[stefanceriu]

the very same PR has been accepted by iOS team (@pixlwave to be more specific) earlier

That's probably because legacy already had that Ring for group calls. For ElementCall on the other hand the notification type has been explicitly defined on the rust side at the request on the VoIP team.

My thought process here is that if we go add a toggle for every single setting folks disagree on then we'll end up in a sea of configuration options we cannot possibly test or maintain properly.

For that reason Element X is taking a different approach and letting the product/design/ux team lead what we do, how and why.

[alexander-potemkin]

the very same PR has been accepted by iOS team (@pixlwave to be more specific) earlier

That's probably because legacy already had that Ring for group calls. For ElementCall on the other hand the notification type has been explicitly defined on the rust side at the request on the VoIP team.

My thought process here is that if we go add a toggle for every single setting folks disagree on then we'll end up in a sea of configuration options we cannot possibly test or maintain properly.

For that reason Element X is taking a different approach and letting the product/design/ux team lead what we do, how and why.

Thanks for diving me into the details! It starts making a bit of sense now.

It looks like you are the person behind that commit, that restricted the calls for 1:1 calls only? If that's correct, would you mind to elaborate on the reasons behind that restriction, please?

[stefanceriu]

It's been a while but I believe I took over and delivered a draft PR from the VoIP team. If I'm not mistaken the logic was that if you start a call in a room then it was probably scheduled by other means (i.e. calendar invites) and that you shouldn't bother the whole room, especially the ones that weren't invited. DMs are more ad-hoc.

The requirements are listed in element-hq/element-meta#2385

[alexander-potemkin]

Yeah, I can see my comments and my screenshot reposted by someone at 2385 :)

I understand the distraction argumentation, but, unless I'm missing something, I can't see anyone saying that group calls must not be able to ring a bell.

Personally I know two various approaches:

• let the ring bell for the group: since I'm part of the group, I might want to get that notification: i.e. - it's a Disaster Recovery group and I want to be on top of everything that is happening there - it is urgent and every minute matters;
• please, don't bother me, I'm working and if I'm part of the group, it doesn't mean I want it to buzz every other time someone hit the ring button.

The PR offered gives the user an option to choose and hence to use the messenger in more use cases. I understand - it's a bit awkward - it tries to work around the fact, that the user level preference lies deeply under the hood - in SDK.

Based on the links you've provided, would it be correct to assume that @manuroe is the person, making the decisions?

If not - how shall I process?
I mean - I hear you are saying that I shall raise an issue at meta project - which I did. But from my past experience, that kind of issues used to leave me nowhere - there are 1.4K of them - it's unpractical to expect anyone to take care of all of them. I would rather not have the efforts of @hek4ek be left in vain. I can also see a demand for the feature from the users, which makes me believe that probably that shall be adjusted at Element side.

[alexander-potemkin]

A gentle reminder

[alexander-potemkin]

@stefanceriu , it is like 2 months passed, with no responce from none of the tickets - nor here, nor at meta project issue raised.
From checking other tickets, it feels like any decision shall pass via product team and I've found an issue that are 9 years old now - still pending product managers decision, making the use of the product extremely complicated for a regular user.

I understand that the product in use by a huge paying customers might have different priorities and that makes sense, so I understand that fork might be a better solution here.

May I kindly ask you to help with one thing only? We've tried changing the line in SDK, that filters out group calls, but the client still didn't raise a call for the group call.
It would be of great help if you could confirm, as per your memory, if SDK is the only place where the group calls are suppressed? Or shall some / any client side modifications be done as well?

I'm trying to make a fork for SDK and client with that setting altered and publish this to the stores - guess, it might ease some pressure (if any) on you and you could consider that as a tests polygon.

Thank you in advance in any way!

[alexander-potemkin]

I understand that tagging everyone would not help (and might even hurt), but I don't know who is the right person to approach. I see that @pixlwave is doing lots of the releases, alongside with Stefan, hope Doug wouldn't mind my gentle ping in here.

[pixlwave]

Fundamentally this isn't our choice to change the behaviour. Your best bet would be to discuss this with the Element Call team over in #webrtc:matrix.org (it's possible they didn't see your ticket in /meta) 🙂

[alexander-potemkin]

Fundamentally this isn't our choice to change the behaviour. Your best bet would be to discuss this with the Element Call team over in #webrtc:matrix.org (it's possible they didn't see your ticket in /meta) 🙂

Thank you very much, Doug - you're always of great help!
Posted, it will work better this time :)