Steps to reproduce:
- Accounting > journal entries > misc
- add entries (draft) with empty journal name
- resquence those entries with entries that have names
Bug:
calling min or sort on the names fails when some are strings and others
are bools (False for empty strings)
Fix:
replace names that aren't set with an empty strings
opw-2957750
closesodoo/odoo#99772
X-original-commit: 0f90852818a334d66ed8a6781f5abdc022f76ff7
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Before this fix, resequencing would use values from _get_sequence_format_() run from an empty model.
This method result is influenced by the sequence_override_regex param of the move journal.
This means that if the journal of the moves that are resequenced has a sequence_override_regex param, it will be ignored in the wizard.
This fix run the _get_sequence_format_() method on the first move to take the journal into account.
Note that the wizard only allows resequencing moves from one same journal.
closesodoo/odoo#98926
Task: opw-2825699
X-original-commit: b22c37a5f173161b4a5f798462ea05142bb9334a
Signed-off-by: William André (wan) <wan@odoo.com>
Have 3 moves named 0, 1 and 2
Delete move 1 to make a hole.
Resequence, starting the sequence at 2.
Expected: new names are 2 and 3
Result: an error because 1 is renamed to 2 but 2 still exists, leading
to a (temporary) duplicated name, which is not allowed.
We clear all the names to be resequenced before doing it in order to
avoid that.
closesodoo/odoo#87836
X-original-commit: bf5173f64582e2675f4121122ce26cb57624e08a
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Issue: When resequencing an account_move, the chatter showed the
resequencing but also a ghost change of state from draft to posted
Steps to reproduce :
1) Create an invoice and post it
2) Look up the journal entry for the invoice and resequence it to some
arbitrary other name
3) Check the chatter for that invoice, it shows a change from draft to
posted
Why is that a bug:
The state isn't changed so it shouldn't be logged
Side-Note: I don't understand why in the code until this commit we had
to force change the state to draft to change the name of the move, when
I tested, we can change the name of a posted move without any issue
opw-2581248
closesodoo/odoo#76394
X-original-commit: e4f5c0d13fb5b04c4a334758c26e442efbb247d4
Signed-off-by: William André (wan) <wan@odoo.com>
- Create 2 invoices (or 2 bills) but let them in draft
- In invoices list view, select all invoices
- Execute Action > Resequence
Resequence wizard will not show.
It comes from a template in resequence renderer using account move name as t-key
that silently crashes because both draft invoices have the same name ("/").
opw-2590273
closesodoo/odoo#73724
X-original-commit: 3e6b7dfd4854069724dde2df43ab2eb7d850e9b5
Signed-off-by: William André (wan) <wan@odoo.com>
The resequence wizard should consider that the sequence is shared for
invoices, journal entries and receipts; only refunds have a separate
sequence.
You could have journal entries in the purchase journal for expense
reports for instance. In that case, we want to be able to resequence all
of it at once.
closesodoo/odoo#68871
X-original-commit: 365da2a0aca1503133433f9dc66b6866e7867974
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Order move for hash: In the method write, we sort the recordset following this rule: by date, by ref and by id.
This rule is used because we need to be consistent with the method _compute_name.
If we don't filter moves like that, we could possibly have a problem.
If you have several moves and you post them at the same moment with the action "Post entries", the hash sequence
could be in another order than the name sequence.
For example:
Move_20 (29/07/2020) - Hash_2
Move_21 (02/07/2020) - Hash_1
About security check, if the hash is activated, the user cannot reorder by date with resequence
because we don't want that the name sequence have not the same order than hash sequence.
Task ID: 2297407
closesodoo/odoo#55669
X-original-commit: b3ae96dc52178a3b13dda845244fe34268aed8a0
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Before, if we had PREFIX/9 and PREFIX/10, the highest number was the
lexicographic order, leading to proposing PREFIX/10 again and again.
Because of performances, we can't execute the regex in the SELECT query
and we need to store it in the database. This will allow to do an
indexed search.
closesodoo/odoo#54811
X-original-commit: 8806f33ef68771834496b764aa4c37b7ccf5841a
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Wrong usage of self in for loops makes some apparently multi-friendly
methods not work correctly when called with a recordset of len > 1.
This commit replaces those references by the correct unique record
reference which should be used at this iteration of the loop, avoiding
potential exceptions or wrong behavior in the concerned methods.
closesodoo/odoo#53320
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Following the new selection feature in list view, we can remove
the custom handling in the resequence action, aiming to perform
the action on the active_domain when all records of the page were
selected.
Part of task 2185145
Task 2146469
Rework the name computation:
* It doesn't use ir.sequence anymore
* It is an editable computed field
* Add a renaming tool
This allows the user to tweak the sequences more easily than having to
get through the ir.sequence settings.
The sequence depends on a parameter of the journal: continuous, montly
and yearly restart of the sequence. Everytime a new period is started,
try to make a pattern form another period.
The incrementing is done by taking the previous name, ordered
lexicographically, splitting it by taking the digits at the end, adding
1 and re contstruct with the prefix.
** This means there could be cases where the prefix has a big importance
on the next number. For instance, if you have
INVOICE/2019/0001
INVOICE/2019/0002
and then rename the last one to INV/2019/0002, don't expect the next
number to be INV/2019/0003. It will be INVOICE/2019/0002 (again) because
the highest number was INVOICE/2019/0001.
You will then end up with
INVOICE/2019/0001
INV/2019/0002
INVOICE/2019/0002
closesodoo/odoo#41485
Related: odoo/enterprise#7189
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Walid HANNICHE (waha)