openerp-expert-framework team mailing list archive

[Gustavo Adrian Marino <gamarino@xxxxxxxxx>]

Nhomar:
Be sure my intention is to contribute to the ecosystem, not to create any
conflict.
I am already a Ready Partner (NUMA Extreme System, located in Buenos
Aires), I am playing by the rules, and also pushing for a better OpenERP.
When I first met OpenERP, I was not running my company, and that's why I am
registered with my personal mail.
I have already made several implementations, with many extensions and
customized modules.

Perhaps my descriptions were not as good or extensive as needed, I am also
not a native English speaker

When I mentioned rich text, I meant the possibility to add enriched text
characteristics (as defined in your Wikipedia reference), like color, font
size o bold text. In no way I was referring to the private RTF format. In
the current state of things, almost all modern systems allows the user to
edit an introduce text with enriched characteristics. In particular sending
mails or making marketing campaigns preparing the templates in raw html
seems to be an artificial limitation today. There are many pretty good open
source javascript libraries providing enriched text editing, so updating
the web interface to provide this capability is something it seems
affordable and it will be very well appreciated by OpenERP end users. The
basic framework should support that for example any text defined field
could contain enriched text. Is a definition to be taken on the framework
and some code to be added to GUI.

OpenERP wiki module seems to be not used in the full potential it could
provide. It could be an extraordinary way to construct a customized
documentation system for OpenERP, but is treated today as a standalone
component with no special care in v6,1 (in fact the implementation of wiki
in v6.1 GUI is supporting less features than before, not even the demo
pages are fully supporting the features they describe). Putting static text
in our modules as the only way to document the system is a bit limited by
current standards (no formatting, no links, no control over presentation,
no media content, no possibility to have links to external/internal
content). If we put some effort in the discussion, we can find a better
solution taking the wiki module into account or any other foreseen method
to provide rich text information. Not to mention, how useful this could be
if we find a way to make it easy to extend and fix when you add your own
module to the system!.
For sure to construct an useful help system is a huge task. Even worse when
the system is a moving target, as an OpenERP system which can be deeply
modified by extension modules. So, let's uses our own OpenERP users to
construct the help system they will consume!
This apply also to tip customization based on current record's info.

>From my experience in the implementation of OpenERP systems, stack traces
are a very limited source of information for issue clearing. In the best
case, they indicate the operation to trigger to reproduce the fault, but
they are very limited without the current data info (something you can get
only with a debug session on server - something not always easy to achieve
in a running system) or at least and indication of the requested operation.
In many cases, they reflect problems in places very far away from the real
issue.
For sure consulting support people you could find many ways to improve this
situation (for example, recording the same information provided by a
debug_rpc_answer with the stack trace, and storing that info in a record
written to the database, that can be mailed to the support team or
consulted via external access the involved db). Many commercial systems
provide expanded trace information and internal logging capabilities.
Ideally, the method could be extended by adding some modules, just in case
someone find additional info useful. Again, something to implement on the
framework

Regarding editing content, I am now sure that using Autocad as an example
was misleading. What I meant by editable content is the possibility to
store some content, that when edited, to trigger an external program to
edit it and get the result back (via mime identification). Ideally this
data could be accesed and generated via method control, so for example this
editable binary field could contain some XML data generated on values
stored in records. Edited XML could be used back to adjust other field
values. XML could trigger from anything from standard programs (eg.
LibreOffice) to very customized applications
A lot of possibilities could be open combining OpenERP with other programs,
providing the user a tool to get advantage of all the applications
ecosystem he use to handle (not limited just to OpenERP). See the path
which many SAS suppliers are following (from SalesForce to Worketc). And
planning to the future, we should be able to think ahead of the current
state of the art!
Again, this is something to implement on the framework (perhaps extending
the current definition of binary fields) and providing the GUI with the
capability to trigger an external program (Something possible today) and to
collect back the edited information to be sent to database (something
currently not possible without the steps described in the first mail). The
example you provided is using different technics to interface using what is
provided today (you can see also what OpenPLM is doing, which by the way
was part of the partner meeting this month).

Running an open source project as big as OpenERP is not an easy job. For
sure you can find several examples on other projects where unbalanced
decisions has lead the whole community to crisis situations (loose of
momentum, breaks, divisions, dispersion or lack of dynamism). The community
out there is also struggling to live in this complex reality, and it is not
always easy to find the time and motivation to play the game of creating
internal momentum. Sometimes is a lot more work getting attention from
OpenERP S.A. than solving the problems. If this happens to often and in an
unbalanced way, the result will be just less people keep trying.

Pushing community to propose new solutions and having such a little
influence on decisions is unbalanced. Keeping planning of new versions as
obscure as today, is unbalanced
We all have to be aware that balance is important, and it is very easy to
believe we are always getting the worse part in the game.

Best regards, and many thanks for your extensive and careful answer


Gustavo Marino
www.numaes.com
gamarino@xxxxxxxxxx


El 25 de abril de 2012 23:21, Nhomar Hernández <nhomar@xxxxxxxxxxxxxx>escribió:

> Hello Gustavo.
>
> Just imaging you want to improve OpenERP and not make a conflict here i
> propose a lot of answers and comments.
>
> 2012/4/25 Gustavo Adrian Marino <gamarino@xxxxxxxxx>
>
>> Hi all
>>
>> If easy to use is a main target, let me propose some points to analyse:
>>
>>    1. There is no way to provide rich text indications on tooltips (I
>>    hope they will be included in v7 as you suggest). No images, no video or
>>    expanded tutorials (provided by implementors, not necessary something to be
>>    generated by OpenERP S.A.)
>>
>>
> Totally agreed, we in Belgium talk about that, some partners have some
> proof of concepts, but nobody has take the time to make the correct merge
> proposal, OpenERP has a vision behind that, they are building a
> Web-Framework that will allow to you customize a lot of thing that today
> are not possible, in this way we can grow up not just in Server in Web
> Client Too!, I hope and i want in GTK too.
>
>
>>
>>    1. There is no way to store information on data base with rich text
>>    capabilities (no text field with rich text edition, no mail or mail
>>    template with rich text direct editing, inclusion of embeded images - from
>>    whithin OpenERP)
>>
>> As you can see:
>
> http://en.wikipedia.org/wiki/Rich_Text_Format
>
> Rich text is a "Propietary Format", i propose that all helps should be
> done in RST (Is Open), i dont like anything privative.
>
> try html widget too!
>
>
>>
>>    1. There is no way to customize the tip based on the current record
>>    status
>>
>> Agreed it should be great!, with the new web client i think it will be
> possible.
>
> But BTW, we use this methodology since v5.0:
>
> Create a method called help_update or somthing like that in your model.
> Overwrite wirte - create method (even read if you need), and put the smart
> part with super.
>
> Write the record.
>
> Train your customer to make ctrl+s & ctrl+R almost all time, it take 2 or
> three huors to develop all validation and personilize what you want with
> help.
>
> In other words, IT is possible.! but should be great if framework help you
> more, with new message system it will be possible for V7.0 I THINK
>
>
>>
>>    1. In form edition, there is no way explain the user which is the use
>>    or purpose of the current record information. A kind of translatable help
>>    system would be helpfull (you can provide contents or not, but currently
>>    there is no way to implement it).
>>
>>
> Same as before, IF your message are translatable _('Put in your code is
> this way') you will be able to translate.
>
>
>>
>>    1. There is no way to connect current form or tree to an OpenERP's
>>    wiki page, and thus allowing the users to construct, improve and expand the
>>    help information by themselves.
>>
>>
> It is possible.
>
> Look the "process engine" click in the interrogation beside the name of
> the view in web client.
>
>>
>>    1. There is no way to connect warnings and exception to help o wiki
>>    content, and thus improving the probability the warning or problem could be
>>    understood by the user
>>
>> True!.
>
> Good Idea,
>
>
>>
>>    1. There is no way to explain the support people what is going on
>>    (out of telling the whole story on the phone).
>>
>>
> mmmmm show me an example of A system do that, it should be great a kind of
> !::::Smart Asistance:::! but BTW the problem is not the framwork is the
> information behind that. And it is work of both OpenERP and Community.
>
>>
>>    1. Why there is no way to record the point where I have a problem and
>>    send it by mail to support people or even better, to record the incident in
>>    the same system?
>>
>>
> Did you try  "chat" module? overwrite it and redirect to your office.
> In GTK configure correctly the client and in HElp > Support you will be
> able to send directly to support the traceback.
>
>>
>>    1. Why not having an internal issue tracking system (for the problems
>>    of the system, not external ones)?
>>
>>
> Did you try crm_issue official module??, this do that. ah! and is great
> with the new Kanban Interface combined with !automated actions! just read
> the book and a little of code.
>
>>
>>    1. There is no easy way to interact on line (chat, google talk, or
>>    whatever) with some other system user to ask for help or advice.
>>
>> Same as before.
>
>
>>
>>    1. There is no way to include editable content (by external programs,
>>    like an Autocad or image processing),
>>
>>
>
> Woao....
>
> Autocad WS after 20 years of the autoccad invention goes up, i know more
> autocad that openERP even, and i need to tell you, there are a lot of work
> behind this request, i think, when Autocad put the specification API public
> it would be possible.
>
> There are some modules from community (amazing must to say) with PLM:
>
> http://www.youtube.com/watch?v=kPaFcUiLWlU
>
> try it, and you will see.
>
> Autocad WS should be a great Improvement, but if you find a customer that
> NEED this, ask him for finance the development it should be great!
>
>>
>>    1. which can be stored in the database.
>>    You can today attach a file. But the user should copy the file, use
>>    the external program to work with, and then update the original attached
>>    file. It is from stone age, very far away from any userfriendlyness
>>
>> Use document_ftp and or document_webdav, almost all programs are able to
> edit directly to FTP and wuala you have it! ;-) is a matter of knowledge of
> implementation not framework (obvious always it can be better).
>
>
>>
>>
>> Implementing a real ERP has a big component of user involvement and
>> trust. An easy to use system, a good purpose sharing tool, an easy support
>> communication tools will help for sure to success and low implementation
>> costs.
>>
>
> This is true, OpenERP is working for it, We community working for test,
> my-your-our customer financing ecosystem, this is the  model Simple and
> Easy... ;-)
>
>
>> If easy to use is an actual main concern, I think it could be a good idea
>> to ask the community BEFORE closing the definition of the v7.
>>
>
> Is not closed, OpenERP Sa develop everything OPEN, try it, online for free
> automated and with the last change made 3 minutes ago!:
>
> http://runbot.openerp.com/openerp-dev.html
>
> If you don't like something AND - im sure it will happend. -
>
> feedback, blueprint, discuss here, more feedback, develop, Merge Proposal,
> probably your first 10 Merge proposal should be denied (to us denied our 15
> first in the middle we were learning), but this is normal and in this way
> works OpenSource Ecosystem.
>
>
>> Most of the presented topics should be solved on the basic platform,
>> which is almost completely controlled by OpenERP S.A, specially regarding
>> the content of new versions, and thus the community has a relative chance
>> to influence on the definition.
>>
>
> For me it is good, i think when OpenERP stablish more solid bases it will
> change a little more, for now, the way is what i mention before,
>
> BTW, if you have 10 customers with OpenERP buy OPW and ask repair
> everything without limits -great yes?- and you will influence A LOT more, I
> love this model ;-) somebody offering WARRANTY and with response in less
> than 24 hours in some cases.
>
> let me share with you an extract of MS licence:
>
>
> http://www.microsoft.com/About/Legal/EN/US/IntellectualProperty/UseTerms/Default.aspx
>
> :::::::::::::::::::
> 20. DISCLAIMER OF WARRANTY. The software is licensed “as-is.” You bear the
> risk of using it. Microsoft gives no express warranties, guarantees or
> conditions. You may have additional consumer rights under your local laws
> which this agreement cannot change. To the extent permitted under your
> local laws, Microsoft excludes the implied warranties of merchantability,
> fitness for a particular purpose and non-infringement.:::::::::::::::::::
>
> What it means..... if MS sell billions of dollars of windows and offer you
> The software is licensed “as-is.”
>
> What do you think can happend with an opensource tool??
> Answer: Study it, make it better, share your code and continue ;-)
>
> In both case the licence and software is AS-IS.
>
>  For sure generating whishlist entries on Launchpad is the official way
>> to go, but the experience shows that they are almost not considered
>> If all the decisions about v7 are already taken, this is just another
>> whishlist
>>
>
> The decistion is hard to follow, be care of your wish lists use social
> media to ask community, make CLEAN and Specific requests, use twitter, i
> promise you we _community_ will share our thought with you and as im doing
> now for free we will help you, if you want to be SURE be heard for OpenERP
> take an OPW too (best choice)  AND mix both helps Community AND OpenERP
> Commercial One.
>
>
> If you want understand _a little bit_ better my POV please see this:
>
> About Business Model:
>
> http://www.slideshare.net/nhomar/the-openerp-ecosystem-business-model
>
> About Community:
>
> http://www.slideshare.net/tiny07/open-erps-community-organisation
>
> About HOW:
>
> *http://doc.openerp.com/v6.0/contribute/index.html#how-to-contribute-link
>
> THANKS for share your POV, the good critics helps everybody grows up !
>
> PS: Sorry for my bad english.
> *
>
>>
>> Best regards
>>
>> El 25 de abril de 2012 12:34, Olivier Dony <odo@xxxxxxxxxxx> escribió:
>>
>> Hi Viktor,
>>>
>>> On 04/24/2012 10:45 AM, Viktor Nagy wrote:
>>> > as per client request I rewrote the share addon to copy the window
>>> action's
>>> > help text too, and make the new shared user with menu tips enabled.
>>>
>>> The term "rewrote" makes me a little bit worried, as this should only
>>> require a
>>> small extension of the original module, right?
>>>
>>>
>>> > I would be happy to make a merge request, but would like to ask first,
>>> if it's
>>> > likely to be accepted or not. The reason why I ask is that first I
>>> thought I'm
>>> > implementing  a new feature, as there were no signs of any
>>> contradictory
>>> > implementations, but than I've noticed that the shared user was
>>> created with
>>> > menu_tips=False on purpose (at least in the sense of having
>>> menu_tips=False in
>>> > the code).
>>>
>>> Yes the menu tips were disabled on purpose for external users because
>>> the way
>>> they are written makes them targeted at normal users of the system. The
>>> tip
>>> itself will usually describe features that are not available to the
>>> external
>>> users, and as such it will be mostly misleading, useless at best. (BTW
>>> the
>>> majority of external users will have read-only access)
>>>
>>>
>>> > So could someone tell me, if this change would be accepted, and if
>>> not, then
>>> > what's the rationale behind the current decision?
>>>
>>> Your patch might certainly be useful for certain kinds of use, such as
>>> for
>>> companies who adapt the default tips in order to make them specifically
>>> helpful
>>> for external users. Was this the case for your customer?
>>>
>>> Perhaps you could publish this feature in a separate module on OpenERP
>>> Apps,
>>> with a clear note in the description that explains that this is not
>>> recommended
>>> with the default menu tips? I'm sure it would be useful for the
>>> community.
>>>
>>>
>>> > My reason for showing the menu tips is that the reason why menu tips
>>> exist is
>>> > to help new users, and to me it's a realistic assumption that shared
>>> users are
>>> > the least trained in OpenERP. Thus every extra info that can help them
>>> should
>>> > be there.
>>>
>>> It's certainly the case, but it seems to me that the default tips would
>>> be more
>>> misleading for these external users than no tip at all, wouldn't they?
>>>
>>> Keep in mind that the current strategy of OpenERP is to be as simple and
>>> intuitive as possible out-of-the-box, just by looking at the screens.
>>> This
>>> means we'd rather improve the UX to make it easier to understand at a
>>> glance
>>> for all users, than include more tips, descriptions and help in the
>>> screens.
>>> More text = more stuff to maintain = more translations to do ;-)
>>> That being said, the menu tips will likely stay in 7.0, and probably be
>>> enhanced to allow rich text and media. But they should be used sparingly
>>> and
>>> their content would still be targeted at the main users first (e.g. what
>>> should
>>> you do when you're starting out with an empty list), not so much at
>>> read-only
>>> external users, who should presumably understand what to do with the
>>> documents
>>> they were shared.
>>>
>>> What do you think?
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openerp-expert-framework
>>> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openerp-expert-framework
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>> --
>>
>> Gustavo Adrian Marino
>>
>> Mobile: +54 911 5498 2515
>>
>> Email: gamarino@xxxxxxxxx
>>
>> Skype: gustavo.adrian.marino
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-expert-framework
>> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-expert-framework
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> --------------------
> Saludos Cordiales
>
> Nhomar G. Hernandez M.
> +58-414-4110269
> Skype: nhomar00
> Web-Blog: http://geronimo.com.ve
> Servicios IT: http://vauxoo.com
> Linux-Counter: 467724
> Correos:
> nhomar@xxxxxxxxxxxxxx
> nhomar@xxxxxxxxxx
> twitter @nhomar
>
>


-- 

Gustavo Adrian Marino

Mobile: +54 911 5498 2515

Email: gamarino@xxxxxxxxx

Skype: gustavo.adrian.marino