The counting is based on the domain of the action. I think it is good to include search_value instead of enforcing more restricted domain because it allow user to clear it and see the full set.
So the search_value will be used to limit on pending records.
Although I agree that buttons look better at the bottom than at the top, I still keep my remarks that we’re duplicating part of the feature already provided by the relate button.
I agree with Cédric that a menu on the right takes horizontal space which is more valuable than the vertical one. However, I tend to look at how gmail solves this kind of problems and here’s a screenshot of the left menu and the right panel (which allow you to have extensions) when they’re hidden:
For the menu in the left, gmail automatically expands it (overlapping the list of e-mails at that moment) when the user is on top of one of the icons for more than a second.
So, it is possible to:
Remove the link button at the top (maybe only when working on a desktop or large enough display) and replace it with a vertical menu which by default shows only the icons with the badge on top.
Badges would only be computed when the keywords have the count set to true. We could decide that counts are not computed if more than one records are selected, as it would be visible in tree view too.
If desired (although it may not be necessary) we could have another boolean at the keyword named “highlighed” (or important). It could make important keywords to be shown alphabetically first. Later non-important keywords could be shown.
I don’t like think the following would be necessary but: we could add a “more” button (
) and display the rest of the keywords in there. But as we can have a vertical scroll, I don’t think that would be necessary.
So IIUC the button will be shown only if the domain returns a record but the badge will shown the count of the domain + the search value? Am I right?
From what I see the current implementation uses the xml view definition to define the links inside the form, so anyone can move the links to a diferent part of the view (top, bottom, in a separate tab,etc.) using the view inheritance system.
In order to implement your proposal we should probably have a dedicated xml tag for toolbar and let the client show as a toggable widget on the (right/left) part form. Something like:
<form>
</form>
<toolbar>
<link1/>
<link2/>
<toobar>
Then we can make it look like:
or
If we go this way we should probably also add support for printing reports and exucting actions for this toolbar.
Then the state and the actions can also be added to the toolbar so we ensure that they are shown on all the tabs.
This are my toughts after reading your comments, not sure if it’s the way to go but just something to think about.
My proposal is not to define this at the view level but use existing keywords.
Yes, that’s what I had in mind too. But wanted to go step by step 
So it seems that there are some other ERPs that they do in a similar way.
Yes, we may go step by step but probably it should not be to hard to support the generic action button.
I like the idea of having most relevant links on the form and add more non relevant options as relate/action/report on the toolbar. This will allow user to focus on important things.
I vote for the rigth (or left) panel. At this time I have a lot of problems with the vertical espace in some screens with a large font configuration. Adding more icons at the top (or the bottom) would increase thoose problems.
Just my opinion.
Cheers!
1 Like
Last version uploaded has an option to hide empty links and added some search value for the party relates. It is ready for testing.
I filled Issue 9189: Add sticky option on group - Tryton issue tracker which I think would be also a good addition for this feature.
1 Like
This topic was automatically closed after 7 days. New replies are no longer allowed.