In case you customize these emails, you do not want
to have them reset when you update the module (-u)
Same thing for the two default value in this file
for event.type
opw-644082
model has been renamed to mail.channel to prepare the slack modeling.
In future commits the mail.group model will be merged with the channel
model from im_chat. The first move is to rename mail.group into
mail.channel to have a model that will unite both features.
In view inheritance, selecting an element based on the attribute `string` is
broken, since this attribute may be translated before the inheritance is
applied. This fixes existing views to avoid such selections.
During tests, some creation of user records would unnecessarily trigger
password reset or set a password, both of which would trigger password
hashing which takes some time (for good reasons).
Fix by:
* passing no_reset_password in YAML tests and some Python tests still
missing it (a number of Python tests already used it)
* removing passwords from YAML records as they're never necessary, the
test user records are not expected to ever log in
Now there should be only one button box per page, and the name should be
"button_box".
Conflicts:
addons/crm/crm_tip_data.xml
addons/event/event_tip_data.xml
addons/fleet/fleet_view.xml
addons/hr/hr_view.xml
addons/hr_recruitment/hr_recruitment_view.xml
addons/project/project_tip_data.xml
addons/purchase/purchase_tip_data.xml
addons/sale_crm/sale_crm_view.xml
addons/website_quote/views/website_quotation_backend.xml
openerp/addons/base/res/res_partner_view.xml
Conflicts:
addons/account_reports/views/partner_view.xml
Conflicts:
addons/claim_from_delivery/claim_delivery_view.xml
addons/stock/stock_view.xml
The stat button count included only reserved seats,
while, when clicking on the button, all attendees
were displayed: draft, confirmed, canceled, done.
Usability speaking, this isn't right.
Besides, once the attendee actually attended the event,
it wasn't anymore included in the count, which is not logical
either: by "Confirmed", you expect the reserved attendees
and the attendees already there.
In addition, on the kanban view, the link said "confirmed" attendees
as well, but redirected to the list with all attendees.
The "expected attendees" value on the kanban was along a "report"
link, bringing to the report where only confirmed seats are displayed.
Kind of non-sense.
Finally, the decision made:
- For an event, the more natural count that you want to see first
is the "expected" attendees, including draft, reserved and attended
attendees.
- Both buttons, on the form view and the kanban view now includes
draft, open and done attendees, and redirect to the list view
displaying only these attendees (canceled excluded).
- On the kanban view, you have a count more including the confirmed
attendees, including the open and the done attendees.
opw-642134
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
Previously, all existing event.mail schedulers were
auto-triggered at each registration, which could
make the behavior unpredictable/surprising,
including during the tests. Only trigger `after-sub`
event.mail schedulers, as only those are related
to a new registration.
Tests fixed to take into account this new behavior.
Rebasing a merge commit with a lot of conflicts is a real pain as every
non-automatic conflicts should be redo manually (especially when there
is a lot of file rename that git cannot follow)
Now,
- event contains the HTML badge fields and the report (and report templates) to print badges
- event_sale add the ticket type on badges
- website_event allow the edition of badge throught website editor.
When the editor will be available in backend, event will be allow to edit badge report, so the action should be moved from website_Event to event module.
First bug, was that the /registration/confirm had never attendee.
Because partner_ids was initialized with set() and so partner_ids &= set(xxx)
will be always empty.
Now the user have confirmation on screen that the registration is done...
Another bug/usuability problem was that when user register to a webinar
less than 1 hours before the event, if scheduler was not run menwhile,
the user has the link after that the webinar was starded...
Now, we force the mail to be send asap, and launch the scheduler at
each confirmation... Anyway, the list of email registration to send should be
never big, because every registration will launch the scheduler.
Test updated since the mail are sent direcly, it's normal to have 0 mail.
to message_add_suggested_recipient; signature has been updated when migrating to the
new API, removing an argument that is now contained in self. However all addons were
not updated accordingly.
- Several Modules have been splitted into several apps
Examples :
Human Resources : Splitted into Leaves, Recruitment, Expenses, Appraisals, Timesheets, Employees, Payroll
Marketing : Mass Mailing, Events, ...
Messaging : Chat, Agenda, Notes, Address Book, ...
- Generally, the related reports have been moved in the apps, as last menu
- Also, configuration menu (no_one group) have been moved into a config root menu
exception made for the warehouse and lunch modules
- Configuration for typical frontend modules have been moved into the website settings
Related modules : Ecommerce, blog, slides, forum
- When they are present, menus like 'product' or 'customers' have been moved
ex : Customers in Sales menu, Product in POS menu
- A lot of sequences and xmlids have been added or modified in this commit
- List of apps :
1 Chat : Inbox, Channels
2 Agenda : Calendar
3 Notes
4 Address Book : The view contact is still laying in the mail module (1 app => 2 icons)
5 eCommerce : Still to define : Config + Orders Analysis + Shipping + incoming Amazon module
6 Sales : Dashboard (Sales Team Kanban), CRM, Sales (note that they are splitted into 2 submenus)
Assignation, After-Sales (Invoicing and Services), Reports
7 Point of Sale : Dashboard (POS status), Orders, Reports
8 Project : Dashboard (Project Kanban), Search (all tasks, issues), Incoming Forecasts module, Reports
Project.issue.version feature has been removed completely
9 Members : Dashboard (Members Kanban), Report, Config
10 Timesheets : Time Tracking, Approvals, Reports
11 Purchase : Purchase, Control (Products and Bills)
12 Warehouse : Dashboard (Warehouse Kanban), Operations, Inventory Control, Schedulers, Configuration
13 Manufacturing : Same menu structure
14 Mass Mailing : Mailings, Campaigns, Reports
15 Events : Events, Reports
16 Lead Automation : Campaigns, Reports
17 Surveys : Surveys, Reports
18 Human Resources : Dashboard (Departments Kanban), Employees, Contracts, Engagement (Gamification)
19 Recruitment : Job Positions, Applications, Resumes & Letters, Reports
20 Expenses : Expenses, Approvals, Reports
21 Leaves : My Leaves, Approvals, Reports
22 Appraisals : Appraisals, Interview, Reports --> Will probably be modified by the incoming refactoring
23 Payroll : Current Menu
24 Lunch : My Lunch, Manager, Configuration
25 Accounting : Same menus currently, waiting the new accounting to be merged
26 Fleet : Current menu
27 Sign : Incoming docusign module
28 No root menuitem with this sequence
29 Attendance : Attendance, Reports
Sign in/out by project feature has been removed completely
30 Link Tracker (group_no_one) : Link Tracker, UTMs
New view added : URL Shortner, which is the frontend view embedded in backend
31 Versionning : Website domain, Versions, Experiments
32 Slides (group_no_one) : Channels, Categories, Slides, Tags
33 No root menu item with this sequence
34 Livechat : Channels, History, Reports
35 Dashboards : My Boards, Configuration
36 App Store : Local Modules, Apps, Updates
Last Settings : Incoming Dashboard Settings, Sales, ...., Website Settings
General Pattern for all modules' settings :
| Module_name
|-- Settings : General Config view (checkbox screen)
|-- Record setting 1
|-- ...
|-- Record setting n
Example for Sale module
| Sales
|-- Settings : Checkbox screen
|-- Quotations
|---- Quotation Templates
|---- Report Layout Categories
|---- Contract Template
|---- Invoice Type
|-- Contract
|---- Deduplicate Contacts
|-- Delivery
|---- Delivery Methods
|---- Delivery Pricelist
The previous filters didn't take timezones into account, and
returned stringified naive datetime values in local browser
time. Those would then be interpreted by the server-side as
UTC date, and depending on the current timezone offset vs UTC,
yield partially incorrect results.
By returning directly a datetime.datetime object instead of
a stringified version (see previous commit 76881fb),
we can get the expected result regarless of the timezone.
Fixes#2972Closes#6229
opw-621282
- New filter "not cancelled" for attendees management
- No more readonly nor invisibility on "minimum number of seats"
- Event questions and mail scheduling have been put under an optional
tab
date_open is not a required field of event.registration.
There is therefore very likely that this field could
not be defined. We should therefore not rely on the fact
it is always defined.
When trying to sent an event mail for an event registration
with a date_open not set (false), the email wasn't sent,
and it prevented the rest of the event mail queue to be
sent as well.
opw-632549
Christophe Simonis