-
Notifications
You must be signed in to change notification settings - Fork 10.9k
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
[NEW] Store the last sent message to show below the room's name by default #10597
Conversation
@sampaiodiego @rodrigok can we get this in? This fits in with our path forward and the desired out of the box user experience. |
I'm not sure about the migration.. it can enable it to instances that have already tested but disabled again on purpose.. if we go this way I think we need to add a proper notice on release notes. |
@sampaiodiego Can't we check I know its false if different. I assume its false if the user modified it at all |
That's a fantastic suggestion @geekgonecrazy |
seems the tests are failing 🤔 |
@graywolf336 what if we change the default to true but let to migrate the server on next version, until there we could receive more feedbacks from the community |
@rodrigok No sir, because by then it will be too late and we won't be viewed as proactive from the community in my opinion. The version of Android which expects this is already out in production, so if we delay then we will only get more issues opened regarding this. Thus I stand behind this pull request and that it should be in this version, not delayed. |
@graywolf336 I don't share your vision, we didn't decided that the last message would be required for mobile now, we have the option to enable and will enable for new installations, just don't want to have big problems with big installations now. So I don't agree with changing all the existent installations to enable this feature. |
@rodrigok When was that not decided? Because the internal discussion that we had a few days ago was quite the opposite of what you're saying now. It was conclusion that because we are moving all three mobile clients to the new "messenger" style views, that this change is needed to be enabled by default because it is breaking the user's experience. Yes, we need to support this setting being disabled on the mobile applications and present it in a nice way but until that happens, which @rafaelks can give us the rough timeline, then we had decided this was the route to go. If you still feel strongly against this, then @RocketChat/core we need everyone's opinions. If you're worried about large servers, then let's just list this change as |
@graywolf336 Yes, I understand, just don't see why we can't execute this in 2 steps. |
I understand @graywolf336 's points and it follows the discussion we had previously, but I liked the two step approach: in this release we say we're changing it to default and make it clear we will enforce that on the next release. also mobile apps updates are much faster then server updates.. so even if we force enabling last message on this release, that does not mean everyone will update the servers and then have a better mobile experience. if the mobile experience is the focus here, it should be done on the mobiles to support servers without last message, since the stores will try to update the apps as soon they're released. |
I share @graywolf336, @geekgonecrazy and @sampaiodiego points guys. This setting was initially created to experiment with it. The internal decision was (copying):
The experience on the mobile apps (Android right now, iOS in near future) is much better with this option available and most of the people don't know about the existence of this setting (it's proved by the negative reviews we had, issues opened, etc). IMHO we can add this migration, the default value but we need to add a WARNING in the release notes talking about it. People are using the app now, not in the future. They upgrade their server and they keep seeing the "No messages yet." message. The experience now is buggy (also client's fault, of course). |
Next release cycle for the mobile apps is in May 27th and there's lots of things we need to do before taking care of this setting disabled, to be honest. This should not be the default experience. |
BTW, if it IS risky to enable it by default and migrate, then I would wait and think more about it. But do we know if this is risky? |
@graywolf336 Is there a way to migrate ONLY if the admin never touched this setting? |
@rafaelks I agree that this should not be the default experience, but we can't turn this feature on by default retroactive before we are sure about the performance impact. So the mobile apps MUST support this feature being off ASAP, even if the mobile team have to do a mid cycle bug fix release. |
@engelgabriel That's not a problem, we can prioritize this change during our release candidate phase next week as we spoke few minutes ago. 👍 But please, let's make sure that this migration gets included ASAP in our back-end (if we find out that it works correctly to everybody) and set the default TRUE to 0.64.0? |
I'll change this PR to remove the migration and keep the default value as true. @rafaelks the mobile could warning the users when accessing a server with the lastMessage setting disabled, something like |
68b2068
to
e7fee81
Compare
e7fee81
to
1f33583
Compare
@engelgabriel @rodrigok @sampaiodiego We're releasing the Android already with this check implemented: |
Closes #10490 - There were some discussions about this a few days ago regarding the mobile applications and their future. Yes, this setting can be disabled and yes the mobile applications need to deal with that possibility but it looks better with this enabled by default as there are several questions and issues raised daily about this.