Skip to content
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

folderNameOfTrash should consider hierarchical trash #350

Open
Veladus opened this issue Jul 30, 2020 · 1 comment
Open

folderNameOfTrash should consider hierarchical trash #350

Veladus opened this issue Jul 30, 2020 · 1 comment
Labels
bug Wrong behaviour that needs to be fixed research

Comments

@Veladus
Copy link
Contributor

Veladus commented Jul 30, 2020

If the trash folder is placed in a hierachy, the upmost directory will be set as folderNameOfTrash effectively making it the Trash. This is caused in folderFromResponse

@Veladus Veladus added bug Wrong behaviour that needs to be fixed LowPriority labels Jul 30, 2020
@JuliaJoch JuliaJoch added the good last issue This is a really hard issue! Better not start with this. label Jul 31, 2020
@shm0sby shm0sby added research LowPriority and removed HighPriority good last issue This is a really hard issue! Better not start with this. labels Jul 31, 2020
@shm0sby
Copy link

shm0sby commented Jul 31, 2020

In ICEndpoint>>folderFromResponse: the folder name for Trash is always the first member of the folderPath array.
If we have a trash folder below Inbox called Inbox.Trash e.g., currently we only take the first member Inbox.

See this loc:
(responseLine includesSubstring: '\Trash') ifTrue: [self folderNameOfTrash: folderPath first].

The idea of simply using ICEndpointFolder>>folderPath which holds Inbox.Trash in the example did not work, because on many sites we get protocol errors for many (strange) reasons. It seems to be more complicated than that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Wrong behaviour that needs to be fixed research
Projects
None yet
Development

No branches or pull requests

3 participants