Display limits of email recovery

[florentos17]

tackling the issue 3219 (duplicated with the issue 3274)

[florentos17]

This curious thing is happening: when accessing the recover deleted messages panel, at first an error is thrown, but when i trigger a hot reload, then everything is fine:

IMG_0450.mov

the method is this:

String getRestorationHorizon(BuildContext context) {
    return ((_session
        ?.props[0] as Map<CapabilityIdentifier, CapabilityProperties>?)
        ?[capabilityDeletedMessagesVault]
        ?.props[0] as Map<String, dynamic>) // line causing the error
        ['restorationHorizon'];
  }

and the error is Type 'Null' is not a subtype of type 'Map<String, dynamic>' in type cast

[github-actions]

This PR has been deployed to https://linagora.github.io/tmail-flutter/3281.

[florentos17]

the issue i had the other day is now resolved, everything is working fine ! it looks like this

in the web version, the options in the dropdown are filtered out so that "30 days" and more do not show if the horizon is 15 days for example. but in the mobile version, the period is selected with this widget (same as the one we get by clicking the little calendar icon in the web version) and i did not want to change the suggested options because the widget is also used for other features.

[chibenwa]

@hoangdat is this work ok?

@florentos17 could you rebase this?

[florentos17]

if it's all good for you then i'll squash and rebase

[hoangdat]

• Must have verifying step after user select Deletion date. In this case, I choose the time range for the last 1 year.

[hoangdat]

why we need this? how about using dependency directly?

[chibenwa]

I remembered it was asked by @tddang-linagora

[tddang-linagora]

We should minimize the using of third party library. If we only need a small function, let's copy it over.

[hoangdat]

from my point of view, we should use 3rd party lib to get the support from the community, don't need effort in maintaining it.

[chibenwa]

Tend to agree with @hoangdat .

Why maintain this code if we have it from a healthy package (size, community, etc..)

[florentos17]

i'll drop the commit removed package duration usages when squashing then (if ok for you @tddang-linagora)

[florentos17]

• Must have verifying step after user select Deletion date. In this case, I choose the time range for the last 1 year.

it is already done on the backend side (the request is modified to be sure it complies with the calendar limit if not already).

but you are absolutely right, we could add a check here on the frontend as well: circle the date in red if invalid and/or refuse to send the request if invalid.

but do you think it’s necessary ? the user is already warned with the yellow banner, and it’s a tiny and hidden feature, so maybe it could be ok to leave it like that ?

[hoangdat]

but do you think it’s necessary ? the user is already warned with the yellow banner, and it’s a tiny and hidden feature, so maybe it could be ok to leave it like that ?

• the best solution: prevent user to select the date range out of the limitation, but for it, huge effort in refactoring the data picker.
• the acceptable solution: warning for unaccepted picked date.

Btw, when I push the recovery request with date time out of limitation, back-end still response the completed status with 0 completion, 0 .... We should have better response for this.

[chibenwa]

the acceptable solution: warning for unaccepted picked date.

Technically with the yellow banner that's already the case.

The option is quite hidden (who knows where deleted message menu is) and is niche. 1% of users will open dead letter menu item. 1% will manually select a date. So we are speaking of user experience for 0.01%.

Are we lying to the user? No, backend will transparently filter data, which is what the banner says. Acceptable.

Can we please move on?