qsm-odoo
2972976962
* mass_mailing, payment, point_of_sale, portal, survey, web, web_tour, website_blog, website_crm_partner_assign, website_event, website_event_questions, website_form, website_forum, website_gengo, website_hr_recruitment, website_links, website_mail, website_mail_channel, website_mass_mailing, website_quote, website_sale, website_sale_options, website_slides, website_twitter This commit reviews the whole "JS side" of the web_editor and website apps. This is a first step to be able to improve them with new and better functionnalities; this commit is not supposed to change any visual behavior. The main goal was to achieve a structure similar to the backend one. Now, the frontend side also has a root widget (like the WebClient) and all other widgets are attached to it one way or another. This allows the benefits of using the 'trigger_up' functionnality for example. As RPC are now mainly done with the `this._rpc` functionnality (being possible thanks to the parent hierarchy), the frontend will also be possible to test thanks to QUnit in a future update (besides the "text" editor side which still requires a refactoring to be able to do that). --- Here are some of the changes: (-) conventions and documentation The code has been updated to follow JS conventions and a lot of code has been commented (around +2000 lines of comment). This also means that lots of functions have been renamed to use camelCase or simply to make their name understandable. See https://github.com/odoo/odoo/wiki/Javascript-coding-guidelines. (-) deprecated: web_editor.base The "web_editor.base" module has been split and does not force the modules which require it to wait for DOM ready anymore. This was indeed slowing loading times, but also prevented to use some modules in some contexts (see the LESS editor use in web_studio which is the subject of another task). Now the "editor context" can be got thanks to the "web_editor.context" JS module with its "get" function. The "web_editor.base" module should probably not be used anymore (see its code and recent updates). (-) new: web.dom_ready If a JS module should wait for the DOM to be ready to be executed, a new JS module has been created: "web.dom_ready". This should always be used in a module which only want to instantiate stuff. Do not extend (or worst, include) classes after DOM ready. (-) website.website The "website.website" module has been split. "website.website" does not return anything useful anymore, it just initialize some miscellaneous stuff, without waiting for the DOM to be ready. You might want to check "website.utils", "website.content.compatibility" or `WebsiteRoot`. Also `website.form` has been deleted (use `this._rpc`), so has been `website.error`. `website.prompt` will be removed in a future update to be replaced by `Dialog.prompt`. (-) widgets are great Many classes which were not widgets are now widgets. This allows them to use the 'events', the 'xmlDependencies' and the 'this._rpc' features for example. Here are some of the main ones: - Snippet options: these were classes with a `$el` for the menu element and `$target` for the customized element. This is still the case but following standard `Widget` structure (one exception: using `this.$(...)` searches in the `$target` as before this update). - Snippet animations: instead of class instances with a `$target` element which can be `start` and `stop`, these are now standard widgets which can be `start` and `destroy`. `this.$target` is an alias to `this.$el` for ease of compatibility. - Snippet editors: instead of class instances in charge of an editor overlay, these are now widgets. Each "child" snippet editor is properly attached as a "child", which allows editors to communicate and to be properly destroyed. (-) root widgets and website navbar The frontend is different of the backend. In the backend, the page has an empty <body/> element and all the components are instantiated from parent to children (i.e. the `WebClient` is instantiated and is in charge of instantiating the `ControlPanel`, etc). The frontend cannot work like that on page loadings as they are way more frequent than in the backend and we do not want them to flicker. A frontend page is loaded as a <body/> element which already contains the website navbar and its menus and the whole content page. JS code has to be "attached" to these existing elements. This is possible thanks to the `RootWidget` instances and the specialized `WebsiteRoot`, `IframeRoot` and `WebsiteNavbar` (see code for details). (-) lazy loading No more (or at least a lot less) XML/JS has to be loaded on page loading, thanks to the use of the `Widget.xmlDependencies` feature. XML which have to be lazy loaded is loaded only on related Widget instantiation if necessary, which allows to execute a lot of JS code before the DOM is ready and to start many widgets on DOM ready (not later). A visual benefit of this is clicking on the 'edit' button as soon as it is possible: before this commit, this was sometimes not doing anything as event handlers were not binded yet. Still a possible exception: loading the session and locales. This may be asynchronous stuff which is still required before widget instantiations but this will be the subject of another task. (-) deprecated code and code location More than reviewing code and organizing it, many apparent dead code was removed. More importantly, mislocated code was put in the right app. This is the case for snippet animations which is a concept for website apps but was defined in the web_editor app, or some translation concepts which were part of website but should have been part of web_editor. --- There are probably more things to say about this commit but I will let the comments speak for those.
134 lines
7.9 KiB
XML
134 lines
7.9 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<odoo>
|
|
<data>
|
|
|
|
<!-- Set demo karma for test tour as demo user-->
|
|
<record id="base.user_demo" model="res.users">
|
|
<field name="karma">20</field>
|
|
</record>
|
|
|
|
<!-- Tag -->
|
|
<record id="tags_0" model="forum.tag">
|
|
<field name="name">Contract</field>
|
|
<field name="forum_id" ref="website_forum.forum_help"/>
|
|
</record>
|
|
<record id="tags_1" model="forum.tag">
|
|
<field name="name">Action</field>
|
|
<field name="forum_id" ref="website_forum.forum_help"/>
|
|
</record>
|
|
<record id="tags_2" model="forum.tag">
|
|
<field name="name">ecommerce</field>
|
|
<field name="forum_id" ref="website_forum.forum_help"/>
|
|
</record>
|
|
<record id="tags_3" model="forum.tag">
|
|
<field name="name">Development</field>
|
|
<field name="forum_id" ref="website_forum.forum_help"/>
|
|
</record>
|
|
|
|
<!-- Questions -->
|
|
<record id="question_0" model="forum.post">
|
|
<field name="name">How to configure alerts for employee contract expiration</field>
|
|
<field name="forum_id" ref="website_forum.forum_help"/>
|
|
<field name="post_type">question</field>
|
|
<field name="views">3</field>
|
|
<field name="tag_ids" eval="[(4,ref('website_forum.tags_0')), (4,ref('website_forum.tags_1'))]"/>
|
|
</record>
|
|
<record id="question_1" model="forum.post">
|
|
<field name="name">CMS replacement for ERP and eCommerce</field>
|
|
<field name="views">8</field>
|
|
<field name="forum_id" ref="website_forum.forum_help"/>
|
|
<field name="content"><![CDATA[<p>I use Wordpress as a CMS and eCommerce platform. The developing in Wordpress is quite easy and solid but it missing ERP feature (there is single plugin to integrate with Frontaccounting) so I wonder:
|
|
|
|
Can I use Odoo as a replacement CMS of Wordpress + eCommerce plugin?
|
|
|
|
In simple words does Odoo became CMS+ERP platform?</p>]]></field>
|
|
<field name="post_type">question</field>
|
|
<field name="tag_ids" eval="[(4,ref('website_forum.tags_2'))]"/>
|
|
</record>
|
|
|
|
<!-- Answer -->
|
|
<record id="answer_0" model="forum.post">
|
|
<field name="forum_id" ref="website_forum.forum_help"/>
|
|
<field name="content"><![CDATA[<p>Just for posterity so other can see. Here are the steps to set automatic alerts on any contract.. i.e. HR Employee, or Fleet for example. I will use fleet as an example.</p>
|
|
<ul>
|
|
<li>Step 1. As a user who has access rights to Technical Features, go to Settings --> Automated Actions. Create A new Automated Action. For the Related Document Model choose.. Contract information on a vehicle (you can also type in the actual model name.. fleet.vehicle.log.contract ) . Set the trigger date to ... Contract Expiration Date. The Next Field (Delay After Trigger Date) is a bit ridiculous. Who wants to be reminded of a contract expiration AFTER the fact? The field should say Days Before Date to Fire Action and the number should be converted to a negative. IMHO. Any way... to get a workable solution you must enter in the number in the negative. So for instance like me if you want to be warned 35 days BEFORE the expiration... put in Delay After Trigger Date.. the number -35 But the sake of testing, right now just put in -1 for 1 day before. Save the Action.
|
|
<li>Step 2. Go to Server Actions and create new Action. Call it Fleet Contract Expiration Warning. The Object will be the same as above .. Contract information on a vehicle. The Action Type is Email. For email address I just put my email. Under subject put in... [[object.name]]. This will tell you the name of the car. Message you can put any text message you like. Now save the Server Action.</li>
|
|
<li>Step 3. Now go back to the Automated Action you created and go to the Action tab next to the conditions tab. Click Add and add the server action you created . In this case Fleet Contract Expiration Warning. Then Save.</li>
|
|
<li>Step 4. To test, set a contract to expire tomorrow under one of your fleets vehicles. Then Save it.</li>
|
|
<li>Step 5. Go to Scheduled Actions.. Set interval number to 1. Interval Unit to Minutes. Then Set the Next Execution date to 2 minutes from now. If your SMTP is configured correctly you will start to get a mail every minute with the reminder.</li></ul>]]></field>
|
|
<field name="parent_id" ref="question_0" />
|
|
<field name="post_type">question</field>
|
|
</record>
|
|
<record id="answer_1" model="forum.post">
|
|
<field name="forum_id" ref="website_forum.forum_help"/>
|
|
<field name="content"><![CDATA[
|
|
<p>Odoo v8 (next release) provides a web module and an e-commerce module: www.odoo.com/page/website-builder
|
|
The CMS editor in Odoo web is nice but I prefer Drupal for customization and there is a Drupal module for Odoo. I think WP is better than Odoo web too.
|
|
</p>]]></field>
|
|
<field name="parent_id" ref="question_1"/>
|
|
<field name="post_type">question</field>
|
|
</record>
|
|
|
|
<!-- Article-->
|
|
<record id="article_0" model="forum.post">
|
|
<field name="content_link">https://www.odoo.com</field>
|
|
<field name="name">Discover Odoo, an open source ERP.</field>
|
|
<field name="forum_id" ref="website_forum.forum_help"/>
|
|
<field name="post_type">link</field>
|
|
<field name="views">6</field>
|
|
<field name="tag_ids" eval="[(4,ref('website_forum.tags_3'))]"/>
|
|
</record>
|
|
|
|
<!-- Discussion-->
|
|
<record id="discussion_0" model="forum.post">
|
|
<field name="name">How to setup a regular PostgreSQL database backup</field>
|
|
<field name="content">I'm not familiar with PostgreSQL database administration , so I figured I might ask for help from someone more knowledgeable on the subject.
|
|
|
|
What would you recommend in order to setup a regular (daily) OpenERP database backup?
|
|
|
|
Ideally, this would be done without stopping the database (hot backup). Is it possible to setup incremental backups, e.g., one weekly reference backup and daily incremental backups?
|
|
|
|
Are there any automation scripts available I might use?
|
|
|
|
(I'm using Ubuntu Server.)</field>
|
|
<field name="forum_id" ref="website_forum.forum_help"/>
|
|
<field name="post_type">discussion</field>
|
|
<field name="views">5</field>
|
|
</record>
|
|
|
|
<record id="reply_1" model="forum.post">
|
|
<field name="forum_id" ref="website_forum.forum_help"/>
|
|
<field name="content"><![CDATA[<p>I use the following setup:</p>
|
|
<ol>
|
|
<li>Backup-Script</li>
|
|
<li>Housekeeping script (deletes backups which are older than 30 days)</li>
|
|
<li>Create daily cronjobs in to run Backup and Housekeeping Script. The backup runs daily at 1am and the housekeeping job runs daily at 5am.</li>
|
|
</ol>]]>
|
|
</field>
|
|
<field name="parent_id" ref="discussion_0"/>
|
|
<field name="post_type">discussion</field>
|
|
</record>
|
|
|
|
<!-- Post Vote -->
|
|
<record id="post_vote_0" model="forum.post.vote">
|
|
<field name="post_id" ref="question_0"/>
|
|
<field name="user_id" ref="base.user_demo"/>
|
|
<field name="vote">1</field>
|
|
</record>
|
|
<record id="post_vote_1" model="forum.post.vote">
|
|
<field name="post_id" ref="answer_0"/>
|
|
<field name="user_id" ref="base.user_demo"/>
|
|
<field name="vote">1</field>
|
|
</record>
|
|
<record id="post_vote_3" model="forum.post.vote">
|
|
<field name="post_id" ref="article_0"/>
|
|
<field name="user_id" ref="base.user_demo"/>
|
|
<field name="vote">1</field>
|
|
</record>
|
|
|
|
<!-- Run Scheduler -->
|
|
<function model="gamification.challenge" name="_cron_update"/>
|
|
|
|
</data>
|
|
</odoo>
|