different partner views

greno · **Joined:** Sat Aug 18, 2007 7:14 am **Posts:** 746

fabien wrote:

> ... It's better to have one big partner view with everything and desactivate or hide some parts according to the partner type. If you create a view for customers and a view for suppliers, what will you so when a partner is a customer and a supplier at the same time ?

This is exactly the point. For a Partner who is both a Customer and a Supplier, you should be able to bring up a Customer form when you are dealing with the Partner as a Customer and be able to bring up a Supplier Form when dealing with the Partner as a Supplier. This is how all MVC apps behave. That's one of the great benefits of MVC, to allow different views of the same model.

Regards,
Gerry

osi · **Joined:** Thu Jul 24, 2008 5:00 pm **Posts:** 51

Hi,

Does the attr parameter allow to filter on groups ? If yes, how ?

How to deal with the print button when giving different acces rights on forms. For example :
- I have 2 tree views with one with less field. If it is the default, how to allows admin users to print all data. If it is the second view, how to print only allowed fields ?
- If you filter using attr parameter, how the print button will be treated by the application ?

Also, if having 2 different tree views, how to make them point to 2 different form views ?

thanks

rvalyi · **Joined:** Fri Jan 25, 2008 8:01 pm **Posts:** 720

Hi guys,

I had the same issue you are mentioning. This is in the fleet_maintenance module in trunk extra addons I created. This module allow our customer to manage their customer stock of VOD servers + maintenance contracts using an extension of the native stock.location. So depending if a location is a fleet or not, different views should be presented.

I first overrided the stock.location view with visible groups depending of the context (what is currently commited), but actually it sucks a bit for several reasons:
* you can't have notebooks inside visible/invisible groups
* you can't have a view with a domain that change depending of the context
* you can't have a field twice with the required attribute that change.
* I override the standard stock.location, making it fragile for other third party extending modules

Finally, it looks like a good method would be to override the fields_view_get method of the stock.location (or your own object) and provide the client the vies that fits the best depending of the context argument.

Anyone trying this? I might try it soon and if so I will give updates on the progress.

Tiny advised to create a buleprint for selecting a view depending on the context declaratively, so without overriding the fields_view_get mdethod.

Hope this helps, definitely an hot topic.

Raphaël Valyi.

rvalyi · **Joined:** Fri Jan 25, 2008 8:01 pm **Posts:** 720

So, just to help out, if you are in trouble with such a problem of selecting the right view for the job (see my previous post), you can still have a look to the fleet_maintenance module from trunk-extra-addons, or look at the relevant part of it here:

Code:

class stock_location(osv.osv):
    _inherit = "stock.location"
    
    
    def fields_view_get(self, cr, uid, view_id=None, view_type='form', context=None, toolbar=False):
        if view_type == 'form' and context.get('fleet_type', False) == 'sub_fleet':
            view_id = self.pool.get('ir.ui.view').search(cr,uid,[('name','=','stock.location.fleet.form.sub_fleet_maintenance')])[0]
        elif view_type == 'form' and context.get('fleet_type', False) == 'fleet':
            view_id = self.pool.get('ir.ui.view').search(cr,uid,[('name','=','stock.location.fleet.form.fleet_maintenance')])[0]
        #elif view_type == 'tree' and context.get('fleet_type', False) == 'sub_fleet':
        #    pass
        #elif view_type == 'tree' and context.get('fleet_type', False) == 'fleet':
        #    pass
        return  super(stock_location, self).fields_view_get(cr, uid, view_id, view_type, context, toolbar)

Fabien told we might create a blueprint to have a similar view selection ability in relation fields in a declarative way with an XML attribute with no need to code like that, any thought? We might create such a blueprint then.

Hope this helps

Raphaël Valyi.