Closed nhomar closed 8 years ago
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.
I understand perfectly.
Now since V.8.0 some things can be done (which is the reason they deprecate document.page).
Let me know if you are agreed to make a proper PoC and show you.
Thanks for your quick answer @max3903
Regards.
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.
@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 ?
@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:
Today, all those targets (procedures, manuals, etc) are document_page record with a different category, so the relationship is easy.
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.
@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.
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 :-(
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 :-)
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
2016-02-05 0:02 GMT-06:00 Holger Brunn notifications@github.com:
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
@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?
2016-02-05 15:04 GMT-06:00 max3903 notifications@github.com:
@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
I used the way it is working now, I will left this closed as documentation only.
Hello.
I appreciate to know before propose any technical improvement, why is this system using document.page instead new techniques "a page - a view" in order to use the full inline editor from the front end?.
It is a real question in order to no overthink things and simply propose improvements and no refactors.
Thanks a lot in advance.
Regards.