| Age | Commit message (Collapse) | Author |
|---|
|
'Unpublished'
Another reason why it’s better to change ‘not archived’ into ‘active’ is
because ‘active’ is the functional name of this field in the filter list in list view.
For the rest, it’s just a better en_US way of saying it.
|
|
|
|
|
|
|
|
|
|
|
|
In the Filters, Group By and Favorites dropdowns,
when clicking outside the `li` elements but still
inside the dropdown menu itself
(like on the dividers,
or next to the advanced search `Apply` button),
the dropdowns was closed.
This behavior was annoying when doing an advanced search
with a field using the datetime picker, as, to close the datetime
picker, you have to click outside it, and when you did, it closed
automatically the filter dropdown... So you had to open it again to
finally apply the filter.
opw-674310
|
|
|
|
The action object, and in particular its context, is modified by the Action
Manager and by some views (e.g. sales_team_dashboard Kanban). So, as the action
is stored in cache, the same object was returned each time the action was
requested, and previous modifications of its context still applied.
This produced a bug with the sales_team_dashboard when following those steps:
- click on the link to today's activities, it opens an action with
'search_default_today' in the context,
- come back to the dashboard
- click on the link to this week's activities, it opens an action with
'search_default_this_week' in the context, but the formerly added key
'search_default_today' is still there as well, so the domain is wrong.
|
|
1/ On create new record focus field should select already existing value of field,
So user doesn't have to remove the old value first and then enter new value.
2/ Forget about it
|
|
This reverts commit c43a97f353b76e211cad939a1c02c06e8ee724b7.
If you use a setTimeout in your js code, you might want to have a
serious look at what you are doing. You are almost certainly doing it
wrong.
If you chain a deferred with the number returned from a setTimeout, you
definitely don't know what you are doing.
If you try to fix editable list view by magically adding timeout,
potentially inversing the order of execution, and without understanding
how deferred works, it is clear that you are just changing stuff until
your particular bug disappear in your particular case, and that you have
no idea what other bugs you just introduced.
Please study how deferred works, how the basic JS methods works, learn
what setTimeout returns. Also, you might want to have a basic
understanding of how and when expressions are evaluated. For example,
if you cannot explain why a if statement cannot be replaced by a
function, you might want to stop what you are doing and educate yourself.
|
|
1/ On create new record focus field should select already existing value of field,
So user doesn't have to remove the old value first and then enter new value.
2/ Avoid the double empty line creation when pressing enter
step to produce
1 Menu Point of Sale > Configuration > Point of Sale switch to form view
2 Tick the box "Cash Control" , the one2many field will be visible
3 Press the "Tab" from keybord , control jumps to "Add an item" button
4 Press "Enter" from keyboad
5 You will see one extra line will be added..
|
|
|
|
When the user visited a view for the second time, the extra actions in the sidebar
were broken. The reason is that the sidebar code modified in place the
fields_view information.
Note: This was not a problem before, because the field_view_get call was done each
time the view was loaded, but now it is cached.
|
|
|
|
- Add two datepickers to specify a range of date/datetime
|
|
I assume the problem was introduced by a forward port. But whatever the case, we
should not ever use the variable 'openerp' in jsland.
|
|
The UserMenu widget needs the user name, but it is available in the
session informations.
|
|
It is already in the web client page source (or more precisely, in the
assets_backent bundle)
|
|
|
|
This commit introduces a mechanism to add information into the session
from a different module, without having to fetch it manually with a rpc.
This is intended to be used with small pieces of info required at the
start of the web client, such as currency informations.
To add information to the session, one can simply inherit from ir.http
and modify the session_info method.
|
|
|
|
|
|
session_instance.js moved from framework/ to services/ and renamed into
session.js, which required to change the bundles in report and web_editor
addons.
|
|
Make sure to define a minimum margin large enough.
opw-678645
|
|
Backport of commit 68b127797e717ee71b5b0552d69f0f4b4e083f03
opw-678645
|
|
|
|
|
|
When a user wrote a wrong value in char_domain field it should raise a warning
message instead of a traceback.
Backport of b3a88b6ed846a13c0cd07cc25ea49bccbdf84aa8
opw:676783
|
|
|
|
|
|
management
1. Rename "Progress (%)" into "Working Time Recorded"
2. Remove tooltip.
3. It should always indicate the exact percentage :
a. if 2 hours planned and 2 hours consumed = 100%
b. if 2 hours planned and 3 hours consumed= 150%
c. in both cases the progression bar should simply stay full.
4. Consider sub task hours
|
|
|
|
M2O use the autocomplete lib to display its content. The problem is
that if a result is empty (or only composed of whitespaces), a
divider is displayed in the dropdown.
Commit 1d9f7d279a74aaf6aaf25f91e2313b23b4122827 was fixing this by only displaying non-empty
name results... but it did not work as many models implement the
name_search method the wrong way.
The new solution is to add a default display for record values which
are empty strings, at the right places in the webclient components.
|
|
Before this commit, many2many list views in wizards did not
handle the blur event at all, which means that the last edited
line was ignored. This is quite a large bug, but not really
visible in our standard install, because we had no many2many
in wizards.
This commit add naive support for blur events. This is only
intended to help the MRP team. A complete solution would
probably involve moving most of the code in One2ManyListView
to X2ManyListView.
|
|
|
|
Form views with a FieldBinaryImage produced a traceback (only visible in the
server-side logs) when creating a new record from an existing one, because the
fields were re-rendered before being updated (in this case reset to their
defaults). In the case of the FieldBinaryImage, as the field wasn't reset yet,
we tried to load the image of a null id, which produced the traceback.
This rev. ensures that the fields are updated before being re-rendered when
switching to another (possibly new) record.
Note: this is spaghetti code, several re-rendering are triggered when switching
between records (e.g., when updating the fields value, when actualizing form
view mode). This should definitely be refactored/simplified.
|
|
Before this rev., if an error occured during an RPC handled by the
data_manager, the RPC result was stored in cache anyway, and there was thus no
other way than refreshing the page to get correct result for that RPC.
|
|
The left margin of the graph doesn't take into account the width of the
maximum Y-axis value. In case the values are high (> 10^7), they are
cropped.
The fix is to adapt the left margin as a function of the size of the
maximum value.
opw-676538
|
|
In case of a line graph, the values of the Y axis are not formatted as
numbers, although they are on the bar graph.
|
|
|
|
|
|
|
|
this commit adds better support in the compatibility layer of the
js framework. This is necessary if one wants to follow the
official tutorial.
|
|
the enable_button call should have been removed...
|
|
Before this commit, in some cases, clicking on 'save' button, then on
other buttons (like 'validate' in invoices) had the unfortunate effect
of applying twice the changes in some cases.
More specifically the problem appears when:
1. an onchange is triggered (for example, taxes in invoices)
2. the user clicks on 'save', buttons are disabled
3. the 'save' actions is completed, the buttons are enabled, but
the on_button_save still does some work: triggering event, and
reloading the view
4. the user clicks on 'validate'
5. the onchange completes, this triggers some more work
Our only protection against such interactions is right now the fact that
buttons are disabled/enabled. In my opinion, there should be a way
to guarantee that actions are properly serialized (that is actually what
a mutex is for... just saying). But the code of the form view/list view is
too coupled, and such changes are quite dangerous. A real refactoring
of those is needed at some point in the future.
|
|
|
|
|
|
|
|
|
