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

[MIG][11.0] mail_digest #225

Merged
merged 13 commits into from
Feb 1, 2018
Merged

[MIG][11.0] mail_digest #225

merged 13 commits into from
Feb 1, 2018

Conversation

simahawk
Copy link
Contributor

NOTE: I've tried to squash the 2 OCA transbot commits but I get tons of conflicts...

simahawk and others added 10 commits January 17, 2018 14:58
Depending on the request  might fail
nevertheless the website should be there to be found.
Fallback to search and use it if possible for digest' site name
When creating digest records within the context of mail composer
(and possibly other contexts) you'll have a `default_template_id`
key in the context which is going to override our safe default.

This is going to break email generation because the template
will be completely wrong and unpredictable. Lesson learned :)
@pedrobaeza pedrobaeza added this to the 11.0 milestone Jan 18, 2018
Copy link
Contributor

@grindtildeath grindtildeath left a comment

Choose a reason for hiding this comment

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

It seems, there's something wrong with message and mail_id params, as a few are unused, Otherwise, looks good !

@@ -3,25 +3,23 @@
<data noupdate="1">
Copy link
Contributor

Choose a reason for hiding this comment

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

to remove.

@@ -77,37 +75,37 @@ def create_or_update(self, partners, message, subtype_id=None):
"""
subtype_id = subtype_id or message.subtype_id
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like this can be removed, as it isn't used in the function.

digest.message_ids |= message
return True

@api.model
def _get_by_partner(self, partner, mail_id=False):
"""Retrieve digest record for given partner.
def _get_by_user(self, user, mail_id=False):
Copy link
Contributor

Choose a reason for hiding this comment

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

mail_id should be renamed mail

:param mail_id: `mail.mail` record for further filtering.

By default we lookup for pending digest without notification yet.
"""
domain = [
('partner_id', '=', partner.id),
('user_id', '=', user.id),
('mail_id', '=', mail_id),
Copy link
Contributor

Choose a reason for hiding this comment

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

mail_id is then mail.id

('mail_id', '=', mail_id),
]
return self.search(domain, limit=1)

@api.model
def _get_or_create_by_partner(self, partner, message=None, mail_id=False):
"""Retrieve digest record or create it by partner.
def _get_or_create_by_user(self, user, message=None, mail_id=False):
Copy link
Contributor

Choose a reason for hiding this comment

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

Again mail_id > mail, message=None to remove, as it's not used

:param message: `mail.message` to include in digest
:param mail_id: `mail.mail` record to set on digest
"""
existing = self._get_by_partner(partner, mail_id=mail_id)
existing = self._get_by_user(user, mail_id=mail_id)
Copy link
Contributor

Choose a reason for hiding this comment

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

mail_id=mail_id > mail=mail

('user_id', '=', self.id)
], limit=1)
if self.env.context.get('foo'):
import pdb; pdb.set_trace()
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems this should be removed.

@simahawk simahawk force-pushed the 11-mig-mail_digest branch 2 times, most recently from 674ad2a to 305fce8 Compare January 19, 2018 09:03
@simahawk
Copy link
Contributor Author

@grindtildeath obsolete params removed. tnx :)

Copy link
Contributor

@grindtildeath grindtildeath left a comment

Choose a reason for hiding this comment

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

Two <data>XML tags to remove and it's fine for me 👍

@@ -0,0 +1,25 @@
<?xml version="1.0" encoding="utf-8"?>
<odoo>
<data noupdate="1">
Copy link
Contributor

Choose a reason for hiding this comment

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

Still this tag to remove.

@@ -0,0 +1,9 @@
<odoo>
<data noupdate="1">
Copy link
Contributor

Choose a reason for hiding this comment

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

Still this tag to remove.

@simahawk
Copy link
Contributor Author

@grindtildeath done

Copy link

@mpanarin mpanarin left a comment

Choose a reason for hiding this comment

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

LGTM


@api.model
def create_or_update(self, partners, message, subtype_id=None):
def create_or_update(self, partners, message):

Choose a reason for hiding this comment

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

is there any reason to still use the partner here? specially since you then get the user_id from the partner.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

some reasons:

  1. this method is called by res.partner _notify method as notification are sent to users but attached to partners. I like to keep the 2 things tied;
  2. message/email recipients are partners (as in std notifications). Again like to keep this in line.

Choose a reason for hiding this comment

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

ok, that makes sense.

@hbrunn
Copy link
Member

hbrunn commented Feb 1, 2018

it's quite hard for me to separate the old commits from the new ones, @simahawk, can you check this?

@simahawk
Copy link
Contributor Author

simahawk commented Feb 1, 2018

@hbrunn the last 3 commits. The former are improvements coming from v10 that were not ported yet.

@hbrunn
Copy link
Member

hbrunn commented Feb 1, 2018

thanks, I was doing something stupid before. I miss a migration script, but given we don't have rules about that to my knowledge, I won't block on this. Any reason not to provide one? Should be just a couple of SQL statements and make the upgrade experience much better.

@simahawk
Copy link
Contributor Author

simahawk commented Feb 1, 2018

@hbrunn main reason, honestly: not needed for my project and not sure I can spend time on it.
I provided info in the README on how to achieve that... in case someone is willing to help. That could be even me in the next future 😉

@hbrunn hbrunn merged commit d8fd94d into OCA:11.0 Feb 1, 2018
@hbrunn
Copy link
Member

hbrunn commented Feb 1, 2018

@simahawk fair enough. But you inspired me to make this PR: OCA/maintainer-tools#324

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants