summaryrefslogtreecommitdiff
path: root/addons/web/static/src/scss/layout_boxed.scss
AgeCommit message (Collapse)Author
2018-12-03[FIX] account,purchase,repair,sale,web: fix report layoutsSébastien Theys
Following BS4 migration and adding sections and notes. ===== Document templates: - Remove margin from <p> in "informations" to allow them to be correctly centered vertically on their container. - Also add a mt- and mb- on their <div> to better handle them going to a new line when there are too many of them. - Add class for section and note to be able to customize them in layouts. - Add class for price_total to be able to customize it in layouts instead of relying on :last-child. - Add "page-break-inside: avoid;" on the "total" table to not split it between pages when it can be avoided. - Fix sale report template "Informations" to use col-auto just like invoice See 6b8d7bb6d68221f77dabb223de4160fdfb87a6f8 ===== Boxed layout: - fix section & note style - fix borders in general - fix the total table Background layout: - fix section style - fix the total table Clean layout: - fix page number vertical align task-1889346 closes odoo/odoo#27782
2018-08-29[FIX] various: clean up portal and reports (sales and invoices)Sébastien Theys
The goal of this commit is to fix the various views and reports of sales and invoices. ====== Portal ====== Fix breadcrumbs Fix BS4 issues, alignment of various elements Better auto resize of the invoice iframe Fix invoice list for draft invoices Fix previous/next document pagers Remove unnecessary monetary widgets (not needed when using t-field if the field is Monetary) Standardize invoice and sale routes: - especially when related to displaying: html, pdf (print and download), text - by using the get_portal_url() also for invoices Add the total on the left column of sales order ================ Section and note ================ Improve general style: - notes in italics - sections: less padding, darker background, no borders ========= Demo Data ========= Fix sales order demo data to appear for the admin (instead of system) PR: #25997 task-1869469
2018-07-27[REF] *: BS4, adapt col-related classesqsm-odoo
col-lg-* -> col-xl-* col-md-* -> col-lg-* col-sm-* -> col-md-* col-xs-* -> col-* col-lg-offset-* -> offset-xl-* col-md-offset-* -> offset-lg-* col-sm-offset-* -> offset-md-* col-xs-offset-* -> offset-* col-lg-pull-* -> order-xl-1 col-md-pull-* -> order-lg-1 col-sm-pull-* -> order-md-1 col-xs-pull-* -> order-1 col-lg-push-* -> order-xl-2 col-md-push-* -> order-lg-2 col-sm-push-* -> order-md-2 col-xs-push-* -> order-2
2018-07-27[REF] *: BS4, review color systemqsm-odoo
Odoo used to declare two main colors: primary and optional (which are purple and turquoise in enterprise). Those were respectively assigned to the 'primary' bootstrap variable and the 'btn-primary' bootstrap variable. BS4, however, does not allow to have a different primary color for buttons. Instead, the 'primary' color is used for all 'primary' related components and utility classes, same as for all other colors. So, if we want to keep our enterprise buttons green, our 'optional' colors had to become our 'primary' color. The old odoo primary is then renamed to the 'odoo' color. The palette of grays is now larger by default and is numbered from 100 to 900 alongside the $black and $white variables. The equivalence for older variables and the way we used them is: $gray-darker -> gray 900 (unused before) $gray-dark -> gray 900 $gray -> gray 700 $gray-light -> gray 600 $gray-lighter-darker -> gray 400 (the old variable was created by us) $gray-lighter-dark -> gray 300 (the old variable was created by us) $gray-lighter -> gray 200 Fortunately, the 'lighter' variations we created fit well in the default BS4 system ! Unfortunately, our $gray-lighter which carried the same function as $gray-200 (see above) is very close to the new default $gray-100 and quite distant from the new $gray-200. This will be handled in the next commit.
2018-07-17[IMP] various: improve section and add note on sale order and invoiceRavi Gadhia
The goal is to be able to more easily create section and notes on sale order, invoice, and quote. ================================ Problems of the existing feature ================================ The problematic part in the existing feature was that the same section had to be defined again and again for every line, instead of being defined only once where it needed to be. There was also no easy way to move them. Those concerns are solved here. Moreover, due to the complexity of the feature, it was hidden by default, requiring a setting and multiple overrides. The new feature is simple enough that it will always be present. ================== New implementation ================== Sections are lines solely used for display purpose, there is no business logic attached to them. They will show as a nice header at the top of the section, and a subtotal at the bottom of the section. We also take the opportunity to add notes, which are just like sections except they are displayed differently and don't include a subtotal. ========= Reasoning ========= We decided to implement it this way, as opposed to creating a proper section model, because it creates less changes in the code. Creating a intermediary section model between the sale order/invoice/quote and their lines would have required to rewrite the entirety of the code associated to them. It would also have required to create a new JS widget to handle on the same view a double-level One2many (or a One2many + group by). The current solution is much easier because it just requires adding 2 buttons, 1 simple field on the corresponding models which even has a NULL default value, and making some business checks (don't apply business to section/note). We tried our best to impact as less as possible the existing models. Notably we didn't want to add any extra field if this was avoidable. This also makes the migration easier. No matter the implementation choice the views/reports had to be updated to display the sections and notes correctly, which has been done. =========== Limitations =========== The current solution has several limitations: * since the sections don't have business logic, it's not possible to make any reporting based on them * any business related to sections has to be computed on the fly by browsing in order all of the lines, notably the subtotal has to be computed on the fly at every display - when sections are moved (drag&drop) on the back-end, the following lines that are part of the section are not moving with the section =========== Technically =========== The commit will: * update the models to add the display_type field (along with related sql constraints to guarantee integrity) * add new buttons at the bottom of the lists to allow creating section and note, along with the existing add a line/product button * add some business checks to not apply business to section/note (product_id and account_id became non-required fields) !!! The most likely cause of potential bugs introduced in this commit would be to have forgotten to add those checks on some places where they would be needed. This is tedious to check but fortunately easy to fix. * update the views to display sections and notes correctly, also made various improvements/fixes to those views (notably to apply B2B/B2C setting more consistently) !!! This is the second likely cause of potential bugs: if the updated views are inherited in a way that is not compatible with the changes. Or if we forgot to apply the changes to some other views. Again this is tedious to check but fortunately easy to fix. Task #53996 PR #25209
2018-06-22[IMP] account*: update invoice page view on customer portaljpr-odoo
*account_payment, l10_in(_sale), sale(_stock), web With this commit: The invoice preview in portal (/my/invoices..) is now the HTML version of the PDF report. The HTML preview is based on the invoice report to closely match what is already done in Odoo. The invoice preview is displayed in an 'iframe', it is mandatory since: 1. Reports are rendered as a separate page as it returns the whole page after rendering, which has tag <html>, <head> etc 2. Reports are having their own layouts and their own assets that we we cannot load in the page directly or it will break the website layout. 3. We can not use report template with t-call because internally reports are using extra params like context_timestamp, company, DateTime, user etc which is used in header/footer -- There will be a chatter (as a modal) to display/see the history of the document -- For responsive purpose, we use new tables with limited column (Description, Quantity and Amount) for responsive purpose (small screen). It also adds some bootstrap classes to reports for responsive purpose. -- The 'Pay Now' button remains if you already paid with 'wire transfer'. -- Add margin after the header and before the footer to look like the real printed document, without alterating the real printed version Task ID: 39876
2018-04-18[REF] *: convert less content to scss contentqsm-odoo
Convert content so that the assets compile on app installation. The style is still broken after this as the variables/mixins/... are not defined in the right order (as it did not matter in LESS but does in SCSS). This commit basically changes: - Variables: @​var_hello -> $var-hello - Mixins: .mixin_world() {} -> @​mixin mixin-world {} - Classes used as mixin: .my_class() -> @​extend .my_class - Here there were no other solution than to convert the use of a mixin call by the use of an extend as a first approximation - LESS functions -> SCSS functions (e.g. fade -> rgba) - Move first variable definition before the variable is used - Still need to make sure last variable definition is at the right place
2018-04-18[REF] *: rename all LESS files to SCSSqsm-odoo
This is a simple renaming without adaptation.