summaryrefslogtreecommitdiff
path: root/addons/mass_mailing_sms/security/ir.model.access.csv
AgeCommit message (Collapse)Author
2020-03-26[IMP] mass_mailing_(sms): Add unblacklisting buttonTiffany Chang (tic)
Previously a blacklisted phone number or email address could only be removed from their respective blacklist by going to the corresponding blacklist view [in mass_mailing_(sms)] and manually archiving/deactiviting the entry. All users could see that an email was blacklisted via an fa-ban icon added next to their corresponding field in the modules: crm, mass_mailing, mass_mailing_sms, and contacts (via extension). This commit adds additional fa-ban icons next to blacklisted phone numbers and makes all instances of these icons clickable to remove them from their corresponding blacklist using a wizard. There are several limitations to this implementation including: 1. If both a mobile and phone number field appear within a crm lead instance, then only the mobile field will indicate if it is blacklisted (due to current implementation of PhoneMixin which only checks 1 phone value against the blacklist and "sms" which returns mobile numbers first). I.e. if a phone field value is blacklisted, but a value is typed into the mobile field, then the phone field will never indicate that it is blacklisted. 2. If someone clicks on a unblacklisting icon after changing the corresponding field value without clicking off the field input, then the latest typed in value will be the one submitted for unblacklisting, which may not actually be blacklisted (due to "is_blacklisted" flag being a computed field and it not having a chance to re-compute to hide the button). 3. If someone changes values in the blacklist, then someone who already has a form open will not see icon disappear until something triggers a re-compute of the "phone_sanitized_blacklisted" flag (this was already the case with the icon, but now a user may try to unblacklist a value that is already unblacklisted.) 4. Since the icon needs to be visible by everyone to indicate whether or not a phone/email is blacklisted, users without corresponding unblacklist permissions will be able to click on the icon. When they click on it, they will be informed they do not have permission to unblacklist. A wizard was determined to be the best way to implement this unblacklisting for the following reasons: - A "Unblacklisting Reason" is needed and will not be stored as a field. - A field widget is unable to do this due to security settings + inability to refresh view after unblacklisting with a "Unblacklisting Reason" without wiping unsaved changes. Additionally, to better align with GDPR, the corresponding form view for the phone/email blacklist has been updated to use the same wizard to track "Reason for unblacklisting". Unfortunately there is no straightforward way to prevent direct "Archive" action, so users are still able to bypass unblacklisting without being asked for a "reason for unblacklisting". Supports task: 2117635 Upgrade PR: odoo/upgrade#939 COM PR: odoo/odoo#45315
2020-02-04[ADD] *: add ir.model.access on all transient modelsMartin Trigaux
Following changes needing ir.model.access on transient models too. Remove groups declaration on the action to move it to ir.model.access when possible. Rules are strict by default with no unlink access by default and high priviledge asked. Adaptations may be needed later. Write access is given as a wizard may need to be modified in case the action triggers an error and the user has to correct a value account*: use account.group_account_user for all transient by default remove account.print.journal relic stock*: use stock.group_stock_user by default survey: survey user can send invitations mail: allow any employee to execute wizards additional verifications are made to ensure they are executed only on the documents the user has access to you give portal access to mail.compose.message as portal still does some actions like posting messages on the forum add ir.rule to avoid reading somebody else messages increase the query count because of undeterminist count crm: saleman for lead2opp, manager for massmailing partner manager for actions linked to partners avoid a write in test_lead_lost sms: any employee can send sms mrp: mrp user can execute wizards give unlink access as making write during do_produce operation base_import: employees can import files delivery: stock user can deliver event_sale: sale user can configure the wizards event user inherit from sale rights gamification: employee can give badge google_service: resolve FIXME hr: add specific rights manager can set a plan according to group on button anyone who can write on an employee can register a departure hr_expense: set rights based on buttons hr_holidays: an approver can make a summary report hr_recruitment: recruiter can refuse a candidate hr_timesheet: can use the wizard if can create a timesheet l10n_eu_service: managers can create fiscal positions mass_mailing: same group as on mass.mailing.list membership: accountant can create invoice from membership payment: accountant can create a link as the source is an account.move keep the payment.acquirer.onboarding.wizard to system user only as it is called during company configuration point_of_sale: PoS manager only can use wizards never create closing_balance_confirm_wizard records product_expiry: stock user has rights on stock.picking product_margin: access from accounting menus repair: same rules as for above models sale: set ir.rule for self wizard only add rule from model introduced in payment to add salesman group sale_crm: saleman can create a quotation from a lead sale_coupon: any saleman can generate coupon add self ir.rule sale_product_configurator: salesman can select product variants snailmail: employee can send letters website: designers can write on website website_crm_partner_assign: same rule as group on action website_sale: sale ACL as for payment.acquirer.onboarding.wizard website_slides: anyone can send invitation base: base.language.*: allow employee (cf lang_install) change.password.user: can not read change password wizard of other users test.*: no access is needed Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review of acl
2019-08-12[ADD] mass_mailing_sms: support SMS in mass mailingThibault Delavallée
PURPOSE SMS are a powerful marketing tool. For instance it is perfect to announce a sale or to communicate a coupon code, to welcome a new customer in a fidelity program, ... Purpose of this task is to integrate SMS sending in batch in mass mailing. It will use same mailing objects but sending SMS instead of emails. Some metrics and flows will have to be slightly updated at the same time. SPECIFICATIONS Create a new application called "Mass SMS" that follows the structure of mass_mailing application. General guidelines * use the fa-comment icon for this module; * add a "Notification type" field to the mailings: email or sms. Set it invisible and set as domain from context when choosing mass mailing or mass sms application (menus / action specific); * adapt the metrics from Mass Mailing to SMS * sent = received = whether the SMS was sent or not; * opened => we don't have this information; * replied => we don't have this information; * clicks = from link tracker (no change of behavior); * bounced = SMS that failed to be delivered because the format is wrong; * exception = any issue when sending SMS; * keep the Mailing Lists menu, hide email related fields on contact model; * settings: hide the "Specific Mail Server" feature Mailing form view * add an "SMS Content" tab between Mail Body and Options. In there, we should have the following fields: * content * opt-out link: provide a link to the Unsubscribe page. Make it as short as possible; * SMS Template * add an "SMS Text Message" Medium; Mailing actions * add an "SMS Sent" smart button. Use the fa-comment-o icon and it should redirect to the same list views as the "Email sent" smart button and list the contacts to which an SMS was sent; * add a "Mobile" field in the list views of the "Email sent" smart button: * adapt the TEST button > Test Mailing modal to SMS (we should have 1 button for Email and 1 for SMS); update description; * default value for the Recipients field should be Name of the current user, work mobile/phone number; * If there are no Work Mobile/Phone numbers set on res.users, display (123)-456-7890 instead; * rename the Send Sample Mail button into Send Sample SMS; * adapt the SEND NOW button > Confirmation modal to SMS. Change the message into "This will send the SMS Text Message to all recipients. Do you still want to proceed?" * hide the following elements: Subject, From, Reply to, Attachments, Mail Server, Mail Body tab; Opened, Replied; * adapt the label of the following "warnings" to SMS * x SMS Text Message(s) have been ignored and will not be sent. * x SMS Text Message(s) are in queue and will be sent soon. * x SMS Text Message(s) could not be sent. Mailing kanban view * hide the following stats: https://nimb.ws/grvBn0: Opened, Replied; Mailing list / contact management * following fields should be left empty: https://nimb.ws/3HBeJL: Opened, Replied; * when browsing through mailing lsits and contacts through the Mass SMS application, update actions and views to hide fields related to email and display only phone-related information; UTM Campaign * form view > Related Mailings tab: the following fields should be left empty if notification type = SMS: https://nimb.ws/nfvr1O: Opened, Replied Mass Mailing > Reporting (mail.trace.report model) * adapt the reporting based on the fact that we do not have the following metrics for SMS: Opened, Replied; Mass Mailing > Configuration > Blacklist * do not display any email information (phone blacklist is about phone); * support phone blacklist. Phone blacklist is therefore a separate model from mail.blacklist to simplify management. It is included in sms sending process like mail blacklist when mailing in mass; Opt-out and blacklist handling * we do support mailing lists because they could come from different sources and are a way to communicate with a specific audience (and not just a list we bought), e.g. subscribe to this list to be kept updated whenever this product is back in stock, or to receive results of this ... * if the SMSing is from a list, opt-out removes ourselves from the list; * if it is from the contact ==> Sent to blacklist; * allow to attach unsubscription links in sent SMS, redirecting to a new route in mass mailing SMS allowing quick unsubscribe and/or blacklist of phone numbers; Error management * if the user clicks on Send Now / Schedule / Test and does not have enough credits, open the "Insufficient credits" modal in a lazy option (aka when having failed statistics linked to insufficient credits); * on the mailing, we however display this failure as : * a message on the mailing kanban view * a message on the top of the form view + same behavior as the mailing and "Could not be sent" https://www.screencast.com/t/BExgd1Gc; LINKS Task 1997464 PR #34424 Original SMS addition: Task 1922163 (4287481)