Management functionality needs a rethink

[sebb <se...@gmail.com>]

I think it is misleading to reference GPDR for distinguishing between
hiding an email and deleting it entirely.

Whilst the motivation might currently be GDPR, there are other reasons
why it is important to be able to remove an email completely. For
example, sensitive data, or just plain wrong import.

I don't think it makes sense to have to configure this at installation level.

I think there needs to be two independent functions: hide email source
and/or mbox entries, and remove them both.

Also, what about attachments? Maybe the only item that needs to be
redacted is an attachment. What happens to other emails that have the
same attachment?
Or maybe the email source needs to be redacted, but the attachment
does not, and is used by other emails.

This whole area needs a rethink: what functions need to be provided
from a user point of view, and how to enable that.

Re: Management functionality needs a rethink

[sebb <se...@gmail.com>]

On Mon, 27 Sept 2021 at 19:22, Daniel Gruno <hu...@apache.org> wrote:
>
> On 27/09/2021 12.09, sebb wrote:
> > I think it is misleading to reference GPDR for distinguishing between
> > hiding an email and deleting it entirely.
> >
> > Whilst the motivation might currently be GDPR, there are other reasons
> > why it is important to be able to remove an email completely. For
> > example, sensitive data, or just plain wrong import.
> >
> > I don't think it makes sense to have to configure this at installation level.
> >
> > I think there needs to be two independent functions: hide email source
> > and/or mbox entries, and remove them both.
> >
> > Also, what about attachments? Maybe the only item that needs to be
> > redacted is an attachment. What happens to other emails that have the
> > same attachment?
> > Or maybe the email source needs to be redacted, but the attachment
> > does not, and is used by other emails.
> >
> > This whole area needs a rethink: what functions need to be provided
> > from a user point of view, and how to enable that.
> >
>
> You list some good arguments here, I think the functionality should
> indeed be split up or enhanced to allow for both, and it should not be
> difficult to handle. Attachments we can probably handle in JS and py
> alone, as I think the attachment data is already sent to the mgmt
> interface, just not used.

There are various other questions to be answered:
- if a document is deleted entirely, what should happen about any Permalinks?
- if an attachment (only) is deleted, what should happen to its references?

These matters need to be discussed, agreed and documented before
adding code that may not be relevant.

Re: Management functionality needs a rethink

[Daniel Gruno <hu...@apache.org>]

On 27/09/2021 12.09, sebb wrote:
> I think it is misleading to reference GPDR for distinguishing between
> hiding an email and deleting it entirely.
> 
> Whilst the motivation might currently be GDPR, there are other reasons
> why it is important to be able to remove an email completely. For
> example, sensitive data, or just plain wrong import.
> 
> I don't think it makes sense to have to configure this at installation level.
> 
> I think there needs to be two independent functions: hide email source
> and/or mbox entries, and remove them both.
> 
> Also, what about attachments? Maybe the only item that needs to be
> redacted is an attachment. What happens to other emails that have the
> same attachment?
> Or maybe the email source needs to be redacted, but the attachment
> does not, and is used by other emails.
> 
> This whole area needs a rethink: what functions need to be provided
> from a user point of view, and how to enable that.
> 

You list some good arguments here, I think the functionality should 
indeed be split up or enhanced to allow for both, and it should not be 
difficult to handle. Attachments we can probably handle in JS and py 
alone, as I think the attachment data is already sent to the mgmt 
interface, just not used.