openerp-expert-accounting team mailing list archive

[Ferdinand Gassauer <office@xxxxxxxxxx>]

On Wednesday 30 June 2010 Olivier Dony wrote:
> On 30/06/10 10:25, Ferdinand Gassauer wrote:
> > @Jay : Review: Needs Fixing
> > 
> > Hello,
> > 
> > <button name="195" type="action" string="Re-Open" states="paid"
> > icon="gtk-convert"/>
> > 
> > I layout_trunk I mainly moved fields around - so this is another issue.
> > 
> > it was possible to merge at the time I last modified the branch.
> 
> I believe those numeric button names have been in your branches forever,
> I think I remember them from the community days workshop.
> 
> Even it's that's not the best API designed, the name of a button (with
> type=action) must *resolve* to the id of an action at the time of module
> installation, but it may not be *hardcoded* to the id of an action
> (which is database-dependent).
> 
> So the above could rather look like:
>    <button name="%(action_account_state_open)d" type='action' ...
> 
> I suppose you ended up with these numeric values by exporting the views
> from a live DB instead of modifying the source XML files.
> 
> This error and similar ones are visible if you look carefully at the
> diff of the merge proposal:
> https://code.launchpad.net/~openerp-commiter/openobject-
addons/chricar_trunk_layout/+merge/24656
> 
> Maybe someone from the community can help Ferdinand fix these problems,
> seeing all the +1 replies? ;-)
> 
> ~
> 
> As for merging (as already discussed), even ignoring the above, it is a
> difficult task because you have modified many different modules ; not
> just views but also python code in sales, accounting, etc.
> 
> You have done a huge and very interesting job on usability, but
> unfortunately this makes the process of reviewing and merging much
> harder (1000+ lines diff that need to be reviewed by different roles).
> 
> Important note to all those in the community that also maintain huge
> branches and would like to see them merged easily in trunk: look at the
> contribution guidelines and create several small feature branches (even
> with dependencies between them), so they can all be proposed, reviewed
> and merged separately. Nothing forbids you then from having your
> personal central branch where you have them all merged.
> 
> ~
> 
> Final word: yes, it may take some more time but our usability team will
> be reviewing your proposal for inclusion in v6, even partial if we
> cannot directly merge your branch for the above reasons.
> We have to consider everything, and most importantly the focus in v6 on
> the simplification of screens.
> 
> 
> I hope this answers some of your questions...
> 

As I said in mail on expert list
* the branch trunk_layout as it is needs fixing - 
** layout changes (combined relocation of fields AND changes of field 
attributes) are not (well) handled by bzr merge / bzr emerge
* it last worked with r 3541

I definitively didn't add such buttons (because of my limited coding 
knowledge) . Nevertheless 
* it would be interesting where these buttons came from.  I only worked from 
bzr repositories and do not have such buttons in my V5 installation from which 
I created diffs which I used to merge into trunk.
* we shouldn't spend much time on this matter, except someone believes that 
there is a "generator" (export) error causing numbered buttons . 

FYI - I will not be able to do much before weekend or beginning of next week.

-- 
regards
Ferdinand Gassauer
ChriCar Beteiligungs- und Beratungs- GmbH
Official OpenERP Partner