[QUESTION] Why is this system using deprecated document.page? about management-system

[hbrunn]

from my side, it's time and lack of funding: Just like that, email templates should be qweb views of course, but every time some technically savvy customer points that out, I happily quote the time I think it costs to re-implement it using state of the art stuff, and then, the issue magically becomes less important :-(

[max3903]

Management systems usually comes with documentation (procedures, work instructions) which provides confidential or at least strategic information only available to employees of the organization. You don't want to have that available on the Internet. This is the main reason why we decided to maintain and port the module.

If you have a better solution, I am listenning.

[nhomar]

I understand perfectly.

Now since V.8.0 some things can be done (which is the reason they deprecate document.page).

1. Page == ir.ui.view object. (If they left just that then your technical reason is perfect. BUT now. we have...
2. Attribute groups on ir.ui.view object allow granularity on ACL to allow external users see a view, the view before did not has that.
   
3. Controllers need to be enable as auth="user", website=False (or so) with those 2 attributes we do not need a new model, all will be done by the core in terms of ACL.
4. We have the inline editor which can be used to create better look and feel on those documents.
5. The inheritance feature can allow us make more fancy the edition of such documents (alá new sale_order online feature).

Let me know if you are agreed to make a proper PoC and show you.

Thanks for your quick answer @max3903

Regards.

[hbrunn]

for many of our customers, document_page is valuable because you get, well, a page without hassle. All the cool features of qweb editing rely on website, and those customers don't want this module installed.

[nhomar]

@hbrunn agree. but you can have fancy web views without website also.

My customers think in that way also.

From the 4 points I mentioned before, the only one we will not be able to use is the "Fancy edition"

But we can have yet a page a few feature without a new model document.page.

Then we can have management system cool, without website, and a glue module website_maangement in order to enable just the headers of the editor.

Are you agee ?

[max3903]

@nhomar I'd like to see a demo then. but I tend to agree with @hbrunn, document_page is a great way to provide a basic documentation to a customer and allow him to maintain it.

One other argument is that depending on the type of management systems, the verification list of an audit or a nonconformity will be linked to different things:

• for quality, you need to relate with procedures
• for environment, you need to relate with environmental aspects
• for health and safety, you need to relate with hazards
• for information security, you need to relate with feared events
• for all of them, you need to relate with manuals

Today, all those targets (procedures, manuals, etc) are document_page record with a different category, so the relationship is easy.

[hbrunn]

Is this really an either or? We should be able to adapt document_page to use current technologies. Then it would basically be a convenience wrapper around qweb views. The reason it works as it does currently is that it was ported to 8.0 as it was, but of course, there's nothing that holds us back to qwebify (if that's a word) it. Just a matter of resources. Well spent, in this case, as I think.

[nhomar]

@hbrunn COOL That's was the reason of my question.

what you answered on your last comment was:

because of time or because a technical decision completely supported?.

I mean Yes, what it is now is GOOD but we can convert it in PERFECT and the reasons you mentioned clarify so much better how can I help to achieve that.

I prefer use directly the views correctly, but use document.page as a wrapper is a good option also, let me test on my side and i will be back with more points.

Thanks in advance.

[nhomar]

Yes @hbrunn I know the feeling... I will try to improve what I think need to be done, of course may be my customer will think it is not important wither and we use it as it Is , I just want to open the question to understand decisions behind the actual approach, that's it :-)

[hbrunn]

when you're on it anyways, how about a module on top of document_page, that just replaces the content field by a reference to an autogenerated qweb view? Then you have what you want while keeping the dependency structure. ...And you'd make the world slightly better with it

[nhomar]

2016-02-05 0:02 GMT-06:00 Holger Brunn [email protected]:

when you're on it anyways, how about a module on top of document_page,
that just replaces the content field by a reference to an autogenerated
qweb view? Then you have what you want while keeping the dependency
structure. ...And you'd make the world slightly better with it

Yes I read your Idea, I think is good, I will think about it.... I had a
simplest approach in mind, but I will thinka and considere that option.

---

Saludos Cordiales

CEO at Vauxoo https://www.vauxoo.com Odoo's Gold Partner.

[image: --]
Nhomar Hernandez
[image: http://]about.me/nhomar
http://about.me/nhomar?promo=email_sig

[max3903]

@nhomar, @hbrunn I am not sure to follow you but if a user can attach and display an image to a document page, that would be nice.

@nhomar Can you move this discussion in OCA/knowledge so we can work on the specifications there?

[nhomar]

2016-02-05 15:04 GMT-06:00 max3903 [email protected]:

@nhomar https://github.com/nhomar Can you move this discussion in
OCA/knowledge so we can work on the specifications there?

Let me first move my side with the customer. Once I have the objective
clear open a new issue and relate it here.

---

Saludos Cordiales

CEO at Vauxoo https://www.vauxoo.com Odoo's Gold Partner.

[image: --]
Nhomar Hernandez
[image: http://]about.me/nhomar
http://about.me/nhomar?promo=email_sig

[nhomar]

I used the way it is working now, I will left this closed as documentation only.