[nemo-qml-plugin-email] Model and storage for autofill emaillist JB#4… #1

dkotin11 · 2021-06-17T14:13:46Z

…7000

okodron · 2021-06-17T14:52:45Z

MR has moved here from https://git.sailfishos.org/mer-core/nemo-qml-plugin-email/merge_requests/71

pvuorela · 2021-06-21T13:13:03Z

Doesn't compile

emailcontactlistmodel.cpp:25:42: error: cannot call member function ‘EmailContactStorage* EmailContactStorage::instance()’ without object

etc. Should be static.

pvuorela · 2021-06-21T13:40:54Z

src/emailcontactstorage.cpp

+}
+
+
+QString EmailContactStorage::name(const int index) const


Minor detail, but const on by-value parameters is a bit unnecessary noise. Shouldn't matter to the caller if the method internally adjusts its own copy.

I like it when the parameters are constant.

It is symmetrical with constant references.
2.very rare, but helps inside the function

pvuorela · 2021-06-21T13:49:30Z

src/emailcontactstorage.cpp

+        return;
+
+    QMailMessageKey incomingKey(QMailMessageKey::status(QMailMessage::Incoming));
+    QMailMessageIdList incomingIds = mailStore->queryMessages(incomingKey);


Should there be a limit here? E.g. 100 newest or something, supposedly needing sorting too.

we are supposed to search across all emails.

There may be rare combinations of initial letters. And none of these combinations will get into the first 100 or 1000.
IMHO, Loading data once is preferable to loading it every time.

but, there were no optimization tests.

we are supposed to search across all emails.

Why? Some mail boxes can be huge, why should some rarely used contact matter? This is anyway just for suggestions, it doesn't need to go look for anyone the user might know of.

Only the user knows who he is looking for (we still do not know how to get into his head)
It is a mechanism for helping search.
During the work of which it is very often necessary to view the all mailbox.

Each new character entered decreases the set of found.
if we want to see always five results (as an example).
We'll get to the end of the box

Example. User types a name - "Dmitriy". He wants to find email [email protected]

Press - D.
Result:
Djen
David
[email protected]
And many others

After Dmi
Dmitriy
[email protected]
DmitriyAK
[email protected]
dmiranom

He is unsure and adds another character. The number of matches has become less than five.
And if there were less than five of them, then we had to sort out the whole emailbox.

We are not showing the last five addresses.
And the last five addresses by the template. Quite often the set will be less than five. And this means that we have to sort through the item box completely.

*five is just an example

Is this done synchronously, in the main thread? In precisely which cases will this EmailContactStorage instance be initialized (which apps is it used in? and is the instantiation and initialization deferred until the user creates the first UI component which includes a recipient entry field, or is it done on email app startup, etc?) Have any benchmarks been done to determine what the effect on email app startup time is, if the user has a synced exchange inbox with 5k emails, for example?

There were no performance tests. This is bad.

Used in еmail on version Aurora 3.4.0
is planned to use it in the calendar on version Aurora 4.0.1

Initialized now on the main thread. No optimization performed

Let's just add some limitation here, shall we? Sort by the newest ones, 100 emails might be short, but just picking a number, 200 could already provide enough relevant contacts.

I have limited the number of letters for the list

pvuorela · 2021-06-21T13:54:29Z

src/emailcontactstorage.cpp

+}
+
+
+QString EmailContactStorage::email(const int index) const


This and above don't seem to be called from anywhere? Could remove?

pvuorela · 2021-06-21T13:55:05Z

src/emailcontactstorage.cpp

+
+EmailContact EmailContactStorage::at(const int index) const
+{
+    return m_storage[index];


Since this takes external requests, could protect the indexing.

super minor style nitpick, obviously feel free to ignore this: I prefer having only a single return statement for cases like this, e.g. return (index < 0 || index >= count()) ? EmailContact() : m_storage[index];

I like it
done

pvuorela · 2021-06-21T13:55:43Z

src/emailcontactstorage.cpp

+}
+
+
+void EmailContactStorage::initialize()


Nothing updates the contacts after start?

The add() function adds contacts.

For one session, only list adding.
Deleting a contact should not remove it from the list (there may be an erroneous deletion)
Renaming should keep the previous contact and add a new one.

I mean you start the app, write emails to 5 people, start writing a new one -> should include the suggestions from the earlier 5, right?

Right.
the names and emails of these five should be added.

pvuorela · 2021-06-21T14:00:44Z

src/emailcontactlistmodel.cpp

+
+QVariant EmailContactListModel::data(const QModelIndex &index, int role) const
+{
+    EmailContactStorage *storage = EmailContactStorage::instance();


The contact storage seems to be used only here and couple other places in this file. As this is kind of thin wrapper, pondering if it warrants to keep these separate or should those be just combined into one class. If the contact store is a heavy object it could be one reason, but now it seems unnecessarily heavy by going through all(?) the messages. And there's nothing refreshing it. If the stuff was instantiated by need, it would be also up-to-date by free.

all right.
This is a thin wrapper. I dont know which is best. Now you can merge. If the storage class grows, it will increase the difficulty.

pvuorela · 2021-06-21T14:02:15Z

src/emailcontactlistmodel.cpp

+
+        QString name = variant.toString();
+        if (!name.isEmpty())
+            storage->removeByName(name);


This doesn't either play well with a common storage of the contacts. If it's allowed to remove duplicates (or why should there be duplicates ever?) those should be removed only from a single instance?

Possibly a bad name.
Duplicates from another model that we don't know anything about in this class.

pvuorela · 2021-06-21T14:04:01Z

src/emailcontactstorage.cpp

+}
+
+// email can have duplicate. We must erase all email duplicates
+void EmailContactStorage::removeByEmail(const QString &email)


Nothing seems to call this.

And consequently nothing needs findByEmail()

Yes you are right. Done

pvuorela · 2021-06-21T14:08:51Z

src/emailcontactstorage.cpp

+
+void EmailContactStorage::add(const EmailContact &contact)
+{
+    auto iter = findByName(contact.name());


Now every insertion loops everything already inserted? Uh.

And why is it not allowing mutiple contacts by the same name? They could be even different persons.

we often correspond with the same people. We will find matches very often. We need to replace the stamp with the latest one.

the name here is the name of the EmailContact (it is not name of Contact).
This is what the user is finding (maybe a name or an address, what the user is finding we don't know). But the EmaiContact name is unique.

pvuorela · 2021-06-21T14:16:30Z

src/plugin/plugin.cpp

@@ -83,6 +85,8 @@ class Q_DECL_EXPORT NemoEmailPlugin : public QQmlExtensionPlugin
        qmlRegisterType<AttachmentListModel>(uri, 0, 1, "AttachmentListModel");
        qmlRegisterUncreatableType<FolderAccessor>(uri, 0, 1, "FolderAccessor",
                                                   "FolderAccessor is created via FolderListModel or similar");
+        qmlRegisterType<EmailContactListModel>(uri, 0, 1, "EmailContactListModel");
+        qmlRegisterType<EmailContactListProxyModel>(uri, 0, 1, "EmailContactListProxyModel");


Commented already earlier on the app side, but this proxy model thing is a bit strange as the proxied source model is set internally. For the app developer the proxy part is almost invisible. Only funkier detail could be that the proxy model is a property in the qt class so that exposes the internals outside.

Then the EmailContactListModel itself is not at the moment used at all on the app side? Does it need to be registered and exposed? Is there need to even have a separate proxy and source or could it all be embedded into a single contact model?

The separation into model and proxy model is needed.
They have different responsibilities and tasks.
Now there is no need for a model outside, fixed it.

There are maybe two things here. One is that a model + proxy might be easier to implement in c++, the other is what gets exposed to QML. Now the QML only sees something that's called a proxy model but does not have visibility to what is the proxy target.

The name having other problems too. "List" is maybe redundant with "model", aren't all models more or less lists? And if the point is to have recent contacts, not necessarily all the contact, the name could indicate that too?

proxy are easier to implement in C++ side.
In QML side model name are EmailContactModel (remove suffix List)

dkotin11 · 2021-06-22T07:39:04Z

Doesn't compile

emailcontactlistmodel.cpp:25:42: error: cannot call member function ‘EmailContactStorage* EmailContactStorage::instance()’ without object

etc. Should be static.

done

dkotin11 · 2021-06-22T16:43:28Z

Description.

Only the user knows what he is finding. He may remember part of the name or part of the email. we don’t know email or name
prepare a list with double data.
name - email and email - email
the first element that the user is finging
second real email address

d.kotin - [email protected]
[email protected] - [email protected]
e.shebanov - [email protected]
[email protected] - [email protected]
friend - [email protected]
[email protected] [email protected]

there is an overuse of data in the list.
But this simplifies further manipulations.

If the data in the list exists, then we change the time to the freshest
Sorting and filtering this list
If there is another list (contact list). you can remove it from our list (function removedublicate, parameter different model)

src/emailcontact.cpp

chriadam · 2021-06-30T01:53:24Z

src/emailcontactlistmodel.cpp

+QHash<int, QByteArray> EmailContactListModel::roleNames() const
+{
+    static QHash<int, QByteArray> names = {
+        {NameRole, "name"},


style nitpick: prefer single space around curly braces, e.g. { NameRole, "name" }, etc

chriadam · 2021-06-30T01:54:22Z

src/emailcontactlistmodel.cpp

+        QModelIndex index = model->index(i, 0);
+        QVariant variant = model->data(index, role);
+
+        QString name = variant.toString();


minor nitpicks: index, variant, and name could probably all be const

good.
like when the maximum constants.
done

chriadam · 2021-06-30T02:02:37Z

src/emailcontactstorage.cpp

+}
+
+// name can't have duplicate
+void EmailContactStorage::remove(const QString &name)


You've probably already answered this elsewhere, if so I apologise: what is the name here? Is it some combination of the display name plus email address? (I assume it must be, otherwise two contacts with the same name but different email addresses would not be able to be represented in the storage, e.g. "[email protected]" / "[email protected]")

no, this is the name (first part of the contact)
remove additional function. Maybe with a bad name

It is needed to work with other models. To remove what other models showed.

The phonbooks model is like that.
It is necessary that this model does not have contacts of another model. This function is just for this

chriadam · 2021-06-30T02:03:23Z

src/emailcontactstorage.h

@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2020 Open Mobile Platform LLC.


I guess this should be 2020 - 2021 now

chriadam · 2021-06-30T02:04:30Z

src/emailcontact.h

+#include <QMailTimeStamp>
+
+
+class Q_DECL_EXPORT EmailContact


Probably not necessary, but could potentially make this a Q_GADGET if we ever think it might be useful to expose the type directly to QML (rather than field-wise via the model roles). But, of course, we can do that when needed, rather than doing so speculatively now, so, never mind.

At the moment, in QML this class is not used directly, only as part the model. Now you don't need to change it to Q_GADGET. Maybe later

pvuorela · 2021-09-01T11:19:46Z

src/plugin/plugin.cpp

@@ -83,6 +85,8 @@ class Q_DECL_EXPORT NemoEmailPlugin : public QQmlExtensionPlugin
        qmlRegisterType<AttachmentListModel>(uri, 0, 1, "AttachmentListModel");
        qmlRegisterUncreatableType<FolderAccessor>(uri, 0, 1, "FolderAccessor",
                                                   "FolderAccessor is created via FolderListModel or similar");
+        qmlRegisterType<EmailContactListModel>(uri, 0, 1, "EmailContactListModel");
+        qmlRegisterType<EmailContactListProxyModel>(uri, 0, 1, "EmailContactListProxyModel");


There are maybe two things here. One is that a model + proxy might be easier to implement in c++, the other is what gets exposed to QML. Now the QML only sees something that's called a proxy model but does not have visibility to what is the proxy target.

The name having other problems too. "List" is maybe redundant with "model", aren't all models more or less lists? And if the point is to have recent contacts, not necessarily all the contact, the name could indicate that too?

pvuorela · 2021-09-01T11:22:22Z

src/emailcontactlistproxymodel.h

+
+signals:
+    void filterChanged(const QString&);
+    void countChanged(int);


If the signals are mostly for qml, it can be better just omit the parameters as qml doesn't use them that much, instead just reads the property value again on changes.

pvuorela · 2021-09-01T11:24:01Z

src/emailcontactlistproxymodel.h

+    virtual int count() const;
+    QString filter() const;
+
+    Q_INVOKABLE void removeDuplicates(QAbstractItemModel *model, const QString &role);


I'd get rid of this. The model should take care itself, not requiring someone else to ask for cleanup.

pvuorela · 2021-09-01T11:24:51Z

src/emailcontactlistproxymodel.h

+
+    QHash<int, QByteArray> roleNames() const override;
+    bool filterAcceptsRow(int source_row, const QModelIndex &source_parent = QModelIndex()) const override;
+    virtual int count() const;


If this isn't meant for inheritance, i'd skip the virtual.

pvuorela · 2021-09-01T11:28:19Z

src/emailcontactlistproxymodel.h

+    Q_INVOKABLE void removeDuplicates(QAbstractItemModel *model, const QString &role);
+
+public slots:
+    void setFilter(const QString &filter);


Why in public slots?

pvuorela · 2021-09-01T11:54:26Z

src/emailcontactstorage.h

+    void remove(const QString &name);
+
+private:
+    using Container = QVector<EmailContact>;


Don't think this indirection provides too much.

pvuorela · 2021-09-01T11:55:35Z

src/emailcontactstorage.cpp

+    } else {
+        if (iter->timeStamp() < contact.timeStamp())
+            iter->setTimeStamp(contact.timeStamp());
+    }


Could see all this becoming cleaner and more efficient with QHash or QSet.

pvuorela · 2021-09-01T11:59:30Z

src/emailcontactstorage.cpp

+    if (storage != nullptr && storage->m_isInit == false)
+        storage->initialize();
+    return storage;
+}


Perhaps said already, but would just move all the content here to the EmailContactListModel which shouldn't need global data.

Actually looks like the models could get broken since they don't follow up any changes on the storage, yet this instance fetching refreshes the data.

pvuorela · 2021-09-01T12:02:02Z

src/emailcontactlistmodel.h

+#include <QAbstractListModel>
+
+
+class Q_DECL_EXPORT EmailContactListModel : public QAbstractListModel


This shouldn't need Q_DECL_EXPORT since it's internal? Same for the contact.

pvuorela · 2021-09-01T12:04:04Z

src/emailcontact.h

+
+    void setName(const QString &name);
+    void setEmail(const QString &email);
+    void setAddress(const QMailAddress &address);


Out of this group only the below timestamp seems to be used. -> could remove everything else. Could be even an option to remove the timestamp and just do new instances per need.

dkotin11 · 2021-09-23T09:51:51Z

Made a number of changes

Erase intermediate classes
Optimized the data list
Removed data caching
Made it possible to set the maximum depth of email-list

pvuorela · 2021-09-28T14:11:01Z

src/src.pro

@@ -28,6 +30,8 @@ PUBLIC_HEADERS += \
    $$PWD/emailmessage.h \
    $$PWD/emailaccountsettingsmodel.h \
    $$PWD/emailaccount.h \
+    $$PWD/emailcontactmodel.h \
+    $$PWD/emailcontactproxymodel.h \


Do you really need these public, that is provided to external c++ projects?

pvuorela · 2021-09-28T14:11:47Z

src/src.pro

@@ -43,7 +47,7 @@ PRIVATE_HEADERS += \

 HEADERS += \
    $$PUBLIC_HEADERS \
-    $$PRIVATE_HEADERS
+    $$PRIVATE_HEADERS \


Sometimes nice to have trailing "" in case more lines are added but here I' not expecting more header categories.

pvuorela

Looking a lot better now than earlier! Some small comments, need to actually get testing this next.

pvuorela · 2021-09-28T14:22:55Z

src/emailcontactmodel.cpp

+    for (QHash<QMailAddress, QMailTimeStamp>::const_iterator i = container.begin(); i != container.end(); ++i) {
+        m_container.push_back(qMakePair(i.value(), i.key()));
+    }
+    qSort(m_container.begin(), m_container.end(), comparer);


qSort is obsoleted in favor of std::sort. Could already use that instead.

good idea
std::somethinks I like more
done

pvuorela · 2021-09-28T14:24:06Z

src/emailcontactmodel.cpp

+}
+
+
+static void push(QHash<QMailAddress, QMailTimeStamp> &container, const QMailAddress &address, const QMailTimeStamp &stamp)


Small thing but commonly nicer to use pointers instead of non-const references. Even if more obvious with this method, you don't commonly see from foo(bar) that it can have side-effects on the passed parameter.

pvuorela · 2021-09-28T14:30:08Z

src/emailcontactproxymodel.h

+    virtual int count() const;
+    QString filter() const;
+
+    Q_INVOKABLE void setMaxCount(const int maxCount);


If no particular need for this, I'd just skip. Can always add later if it seems necessary. Would be anyhow more of a property thing.

replaced on property

pvuorela · 2021-09-28T14:32:41Z

src/emailcontactproxymodel.cpp

+{
+    if (m_filter != filter) {
+        m_filter = filter;
+        invalidateFilter();


Shouldn't this be called after the real filter, the regexp, has been updated?

Yes you are right.
done

pvuorela · 2021-09-28T14:34:25Z

src/emailcontactproxymodel.h

+
+    Q_INVOKABLE void setMaxCount(const int maxCount);
+
+public slots:


No need to declare slot for filter if it's already a property. Better if the qml doesn't get a chance to call both filter = "foo" and setFilter("foo")

pvuorela · 2021-09-28T14:36:58Z

src/emailcontactmodel.cpp

+    }
+}
+
+


Minor nitpicking, but commonly the separation is just one line :)

pvuorela · 2021-09-28T14:44:27Z

src/emailcontactmodel.cpp

+        return;
+
+    QMailMessageKey incomingKey(QMailMessageKey::status(QMailMessage::Incoming) & ~QMailMessageKey::status(QMailMessage::Trash));
+    QMailMessageIdList incomingIds = mailStore->queryMessages(incomingKey);


Could use the limit parameter here and in the next query?

pvuorela · 2021-10-07T08:13:05Z

src/emailcontactmodel.cpp

+    }
+
+    QMailMessageKey outgoingKey(QMailMessageKey::status(QMailMessage::Outgoing));
+    QMailMessageIdList outgoingIds = mailStore->queryMessages(outgoingKey, QMailMessageSortKey(), maxCount);


With the max count used on two queries the result might be up to 2*maxCount. That's fine if the max count is specified to be kind of per direction, but now that it's exposed as property on the proxy model, it's now behaving well. Easiest way to avoid that would be to get rid of the max count in the proxy model side. Though suppose it would be possible to fetch both incoming and outgoing in a single query.

I wanted the maxCount parameter to be set externally.
This is the reason why he is in the proxy-model.

In requests I can do maxCount / 2

If I do this, then I am specifying the exact value, not its order.
There may be no incoming or outgoing email, If the value is accurate, this must be taken into account. That's why I did maxCount, not maxCount / 2

t doesn't really matter to me

I wanted the maxCount parameter to be set externally.

Is there some reason to? Haven't still seen anything actually using the property.

In requests I can do maxCount / 2
If I do this, then I am specifying the exact value, not its order.

At least it's then the maximum value. Might be lower but the "promise" is kept, so guess fine by such.

done maxCount / 2 now

pvuorela · 2021-10-18T12:13:53Z

src/emailcontactmodel.cpp

+    QMailMessageKey incomingKey(QMailMessageKey::status(QMailMessage::Incoming) & ~QMailMessageKey::status(QMailMessage::Trash));
+    QMailMessageIdList incomingIds = mailStore->queryMessages(incomingKey, QMailMessageSortKey(), maxCount / 2);
+
+    for (const auto& id: incomingIds) {        


Nitpick: bunch of trailing space here.

pvuorela · 2021-10-18T12:30:56Z

src/emailcontactproxymodel.h

+
+    QHash<int, QByteArray> roleNames() const override;
+    bool filterAcceptsRow(int source_row, const QModelIndex &source_parent = QModelIndex()) const override;
+    virtual int count() const;


For minor detail wonder why this is virtual when the other getters aren't.

For bigger detail the countChanged() signal seems to be emitted explicitly from setFilter() and setMaxCount() which doesn't feel like the proper thing to do. Is this property even needed? Simplest to just drop.

pvuorela · 2021-10-18T12:31:07Z

src/emailcontactproxymodel.h

+    QString filter() const;
+    int maxCount() const;
+
+public:


Why a second public:?

pvuorela · 2021-10-18T12:32:15Z

src/emailcontactproxymodel.h

+signals:
+    void countChanged(int);
+    void filterChanged(const QString&);
+    void maxCountChanged(int);


Minor thing, but with the model being private, i.e. only for qml, the signal parameters don't provide much.

…7000

pvuorela · 2021-12-10T08:34:37Z

src/emailcontactmodel.h

+    int rowCount(const QModelIndex &parent = QModelIndex()) const override;
+    QVariant data(const QModelIndex &index, int role = Qt::DisplayRole) const override;
+
+    Q_INVOKABLE void initialize(const int maxCount);


Such a thing still shouldn't exist on the api and not spotting any usage either.

pvuorela · 2021-12-10T08:35:10Z

src/emailcontactmodel.h

+    QHash<int, QByteArray> roles;
+    QList<QPair<QMailTimeStamp, QMailAddress>> m_container;
+
+    const int portionMultiplier = 5;


Seems used only in the .cpp so shouldn't be included in the header.

pvuorela · 2021-12-10T08:37:10Z

Title is "Model and storage for autofill emaillist" but there's only the model now?

pvuorela · 2021-12-10T08:40:08Z

src/plugin/plugin.cpp

@@ -83,6 +84,7 @@ class Q_DECL_EXPORT NemoEmailPlugin : public QQmlExtensionPlugin
        qmlRegisterType<AttachmentListModel>(uri, 0, 1, "AttachmentListModel");
        qmlRegisterUncreatableType<FolderAccessor>(uri, 0, 1, "FolderAccessor",
                                                   "FolderAccessor is created via FolderListModel or similar");
+        qmlRegisterType<EmailContactModel>(uri, 0, 1, "EmailContactModel");


Since this is not actually a generic email contact model but rather a model for recent email contacts, the name could indicate that. RecentEmailContactModel or something like that?

pvuorela reviewed Jun 21, 2021

View reviewed changes

dkotin11 force-pushed the omp-jb47000 branch from d6db4e9 to 997c1f0 Compare June 23, 2021 07:57

chriadam reviewed Jun 30, 2021

View reviewed changes

src/emailcontact.cpp Outdated Show resolved Hide resolved

chriadam reviewed Jun 30, 2021

View reviewed changes

dkotin11 force-pushed the omp-jb47000 branch 5 times, most recently from c02e603 to 746ff68 Compare July 5, 2021 14:52

pvuorela reviewed Sep 1, 2021

View reviewed changes

dkotin11 force-pushed the omp-jb47000 branch 3 times, most recently from 4e5729e to f65a2a6 Compare September 2, 2021 12:33

dkotin11 force-pushed the omp-jb47000 branch from f65a2a6 to d51d1c8 Compare September 2, 2021 13:02

dkotin11 force-pushed the omp-jb47000 branch 2 times, most recently from 89ac114 to f39e70b Compare September 23, 2021 08:04

pvuorela reviewed Sep 28, 2021

View reviewed changes

dkotin11 force-pushed the omp-jb47000 branch 3 times, most recently from b997332 to db444e6 Compare October 1, 2021 07:35

pvuorela reviewed Oct 7, 2021

View reviewed changes

dkotin11 force-pushed the omp-jb47000 branch from db444e6 to d5139b1 Compare October 7, 2021 14:58

pvuorela reviewed Oct 18, 2021

View reviewed changes

src/emailcontactproxymodel.h Outdated

QString filter() const;

int maxCount() const;

public:

Copy link

Contributor

pvuorela Oct 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why a second public:?

pvuorela reviewed Oct 18, 2021

View reviewed changes

[nemo-qml-plugin-email] Model and storage for autofill emaillist JB#4…

6df9439

…7000

dkotin11 force-pushed the omp-jb47000 branch from d5139b1 to 6df9439 Compare December 1, 2021 12:37

pvuorela reviewed Dec 10, 2021

View reviewed changes

		@@ -0,0 +1,39 @@
		/*
		* Copyright (c) 2020 Open Mobile Platform LLC.

		#include <QAbstractListModel>


		class Q_DECL_EXPORT EmailContactListModel : public QAbstractListModel

		}


		static void push(QHash<QMailAddress, QMailTimeStamp> &container, const QMailAddress &address, const QMailTimeStamp &stamp)


		Q_INVOKABLE void setMaxCount(const int maxCount);

		public slots:

[nemo-qml-plugin-email] Model and storage for autofill emaillist JB#4… #1

Are you sure you want to change the base?

[nemo-qml-plugin-email] Model and storage for autofill emaillist JB#4… #1

Conversation

dkotin11 commented Jun 17, 2021

okodron commented Jun 17, 2021

pvuorela commented Jun 21, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dkotin11 commented Jun 22, 2021

dkotin11 commented Jun 22, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dkotin11 commented Sep 23, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pvuorela left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment