[11.0][WIP] stock_operating_unit #132

meigallodixital · 2018-07-09T14:41:36Z

Initial proposal

AaronHForgeFlow · 2018-07-09T15:30:30Z

Thank you for the PR!

It seems the commit history is missing somehow. Don't worry, that happens sometimes. You can fix it without closing the Pull Request, doing something like this:

First, save your changes before doing anything (just copy the folder in another place) and then:

$ git reset --hard origin/11.0  
$ git format-patch --keep-subject --stdout origin/11.0..origin/10.0 -- stock_operating_unit | git am -3 --keep

Then, you just need to put the changes back (just copy the folder you saved before) and:

$ git add .
$ git commit -m '[MIG]stock_operating_unit to v11'
$ git push -f meigallodixital/11.0-stock_operating_unit

That should do the thing 😃

meigallodixital · 2018-07-09T15:56:25Z

Done.

AaronHForgeFlow · 2018-07-09T16:07:05Z

It seems this PR has not been updated. Did the "git push" succeed?

meigallodixital · 2018-07-09T17:28:35Z

Hum, my branch is operating unit not 11.0-stock_operating_unit, this is a branch. I do push for repo and I give ok. I verified that this branch was active.

I can try again, but at home I have a bad internet connection, it will take a while.

Edit: When I do second command 'git format-patch ...', directory stock_operation_unit is created again.

AaronHForgeFlow · 2018-07-10T07:20:06Z

@meigallodixital the branch you used to create the PR is 11.0-stock_operating_unit.

Yes, the git format-patch command is copying the module from v10 and the history. Then you put your changes over it. Thus, your changes are on top and previous commits from previous Odoo versions remain and all history is kept.

I know at first it's a bit tricky but don't worry we will hep you.

* Replace <openerp> and <data> elements by <odoo> * Remove spaces in strings introduced because of \ * Remove exclamation points in error messages * Remove most of the \ where it can be replaced by parenthesis

…n pickings

… suppliers

AaronHForgeFlow · 2018-07-10T07:46:02Z

I edited your branch 11.0-stock_operating_unit to repair the history. Now, the history is fine. You can now reset --hard to meigallodixital/11.0-stock_operating_unit and keep working.
Regards.

meigallodixital · 2018-07-10T09:02:37Z

Thank you very much. The reset should not be against "origin/11.0-stock_operating_unit"?

Apart from the issue of permissions we have not detected any more problems. The problem here is the dependence of this module with #114

AaronHForgeFlow · 2018-07-10T09:09:56Z

@meigallodixital it depends on the name of your remote. Origin could be OCA or could be your fork it depends how you did the clone. Do git remote -v and you will see where origin is pointing to.

Yes it depends on account_operating_unit, that's why it's red. Moreover there are conflicts on the other PR. That one needs to be fixed.

meigallodixital · 2018-07-10T10:00:40Z

I synchronized my repository with oca using the github web interface. That created a pr and merge commit. I think the problem could come from that. My remotes are:

origin  https://github.com/meigallodixital/operating-unit.git (fetch)
origin  https://github.com/meigallodixital/operating-unit.git (push)

And my branchs are:

11.0
* 11.0-stock_operating_unit

The push command of yesterday we did against that branch.

I usually use checkout + rebase. I do not have much experience with github, then i decide use 'standard way' that it proposed. I come from bitbucket and slowly we are migrating to gitlab. :P

AaronHForgeFlow · 2018-07-10T10:28:36Z

All right, that's fine, origin is your fork so you can reset hard to "origin/11.0-stock_operating_unit".
Regards

meigallodixital · 2018-07-10T12:01:08Z

I detect that the first warehouse (warehouse ID = 1) created in the odoo installation is assigned to the operation unit OU1 (operation unit ID= 1) when operation_unit_of_stock is registered:

(stock_warehouse)
id |name        |active |company_id |partner_id |view_location_id |lot_stock_id |code |reception_steps |delivery_steps |wh_input_stock_loc_id |wh_qc_stock_loc_id |wh_output_stock_loc_id |wh_pack_stock_loc_id |mto_pull_id |pick_type_id |pack_type_id |out_type_id |in_type_id |int_type_id |crossdock_route_id |reception_route_id |delivery_route_id |default_resupply_wh_id |create_uid |create_date         |write_uid |write_date          |buy_to_resupply |buy_pull_id |operating_unit_id |
---|------------|-------|-----------|-----------|-----------------|-------------|-----|----------------|---------------|----------------------|-------------------|-----------------------|---------------------|------------|-------------|-------------|------------|-----------|------------|-------------------|-------------------|------------------|-----------------------|-----------|--------------------|----------|--------------------|----------------|------------|------------------|
4  |Vigo 1      |true   |1          |           |33               |34           |V1   |one_step        |ship_only      |35                    |36                 |37                     |38                   |18          |20           |21           |19          |18         |22          |15                 |13                 |14                |                       |6          |2018-07-05 11:45:42 |6         |2018-07-09 14:22:47 |true            |21          |9                 |
1  |Central Gal |true   |1          |1          |11               |12           |GAL  |one_step        |ship_only      |13                    |14                 |15                     |16                   |2           |3            |4            |2           |1          |5           |4                  |2                  |3                 |                       |1          |2018-05-14 14:11:21 |1         |2018-07-09 14:06:45 |true            |5           |1                 |

If I set operating_unit_id field in the table stock_warehose to NULL, then it works as expected.

The record in the database that does not appear (1) and one that appears (9) in the operating_unit table are identical:

(operating_unit)
id |name                |code |active |company_id |partner_id |create_uid |create_date         |write_uid |write_date          |
---|--------------------|-----|-------|-----------|-----------|-----------|--------------------|----------|--------------------|
9  |Vigo 1              |VG1  |true   |1          |1          |1          |2018-07-04 12:23:28 |1         |2018-07-04 12:23:28 |
1  |Main Operating Unit |OU1  |true   |1          |1          |1          |2018-07-03 14:30:37 |1         |2018-07-03 14:30:37 |

Then it does not make sense that one shows up and one does not, because they are equal ...

AaronHForgeFlow · 2018-07-10T12:23:18Z

stock_operating_unit/security/stock_security.xml

+<odoo noupdate="1">
+    <record id="ir_rule_stock_warehouse_allowed_operating_units" model="ir.rule">
+        <field name="model_id" ref="stock.model_stock_warehouse"/>
+        <field name="domain_force">['|',('operating_unit_id','=',False),('operating_unit_id','in',[g.id for g in user.operating_unit_ids])]</field>


@meigallodixital you should be able to see a warehouse if the user has access to the operating unit of the warehouse or the warehouse is not assigned to an operating unit.

In your case if the warehouse is not assigned to any operating unit you should be able to see it. I think the access rule is correct.

Yes, as I said, the code and the xml file of permissions seem good. The records in the database are the same, but I don't see the store that creates the installation when the company is created. The following that are created works ok.

It only occurs to me that the permissions of another module are affecting ...

Note: I did not answer before because github did not notify me of this review ...

AaronHForgeFlow · 2018-07-12T08:06:24Z

stock_operating_unit/data/stock_data.xml

+<odoo noupdate="1">
+
+    <record id="stock.warehouse0" model="stock.warehouse">
+        <field name="operating_unit_id" ref="operating_unit.main_operating_unit"/>


Here is assigning "Your Company" warehouse to the Main OU. The other warehouses remain without any OU.

Yes. The warehouse (not the store ...) that is assigned to the Main Organizational Unit is the only one that is not shown. But I do not see any error in code or difference in the database, as I said before.

That's why I think some permission from another module may be overwriting me that permission rule.

To clarify. I do not have to select the Warehouse even in the user permissions. I do not think the problem is in these rules that we are commenting, since they read permissions from that configuration. And there, the Warehosue with Main OU does not appear to select.

I attach screenshots:
Operating Units: https://snag.gy/QJtxbs.jpg
Warehouses: https://snag.gy/WAJSCv.jpg
Main OU: https://snag.gy/9Wzplq.jpg
Assign OUs to user screen: https://snag.gy/ohNA5a.jpg

AaronHForgeFlow · 2018-07-12T08:40:46Z

When the PR for the account_operating_unit fixes the git conflicts I'll include here that PR in oca_dependencies so we all can test on the same environment and we are on the same page.

nikul-serpentcs · 2018-08-30T09:33:56Z

stock_operating_unit/view/stock.xml

+        <field name="model">stock.warehouse</field>
+        <field name="inherit_id" ref="stock.view_warehouse"/>
+        <field name="arch" type="xml">
+            <xpath expr="//field[@name='company_id']" position="after">


@meigallodixital IMHO remove xpath and Directly use <field name="Field Name" position="after"> everywhere.

Ok, I try to revise that. Thanks.

bjeficent · 2019-01-31T10:35:19Z

Hi @meigallodixital, are you still working on this?

meigallodixital · 2019-01-31T11:59:38Z

Hi @meigallodixital, are you still working on this?

We are considering migrating to version 12.0 now. I have been testing it in January. We notice that it seems that the development is slightly more agile in this version. Version 11.0 took a lot more time to migrate many modules than what is taking 12.0.

We do not want this to be seen as a complaint, but here I am only myself for development and implementation (we are the final user) so it is a purely logistical and time issue.

I think I can review and test the code to close this module ASAP

bjeficent · 2019-01-31T12:08:27Z

Hi @meigallodixital, are you still working on this?

We are considering migrating to version 12.0 now. I have been testing it in January. We notice that it seems that the development is slightly more agile in this version. Version 11.0 took a lot more time to migrate many modules than what is taking 12.0.

We do not want this to be seen as a complaint, but here I am only myself for development and implementation (we are the final user) so it is a purely logistical and time issue.

I think I can review and test the code to close this module ASAP

I have migrated this module to version 12.0, there is an open PR #151. I have asked you because I have the code already migrated (there are few changes to do) but after that I have verified that you already had an open PR. If you are busy I can open a PR if you want, of course 😄

meigallodixital · 2019-01-31T12:14:31Z

Hi @meigallodixital, are you still working on this?

We are considering migrating to version 12.0 now. I have been testing it in January. We notice that it seems that the development is slightly more agile in this version. Version 11.0 took a lot more time to migrate many modules than what is taking 12.0.
We do not want this to be seen as a complaint, but here I am only myself for development and implementation (we are the final user) so it is a purely logistical and time issue.
I think I can review and test the code to close this module ASAP

I have migrated this module to version 12.0, there is an open PR #151. I have asked you because I have the code already migrated (there are few changes to do) but after that I have verified that you already had an open PR. If you are busy I can open a PR if you want, of course 😄

meigallodixital · 2019-01-31T12:16:49Z

Hi @meigallodixital, are you still working on this?

We are considering migrating to version 12.0 now. I have been testing it in January. We notice that it seems that the development is slightly more agile in this version. Version 11.0 took a lot more time to migrate many modules than what is taking 12.0.
We do not want this to be seen as a complaint, but here I am only myself for development and implementation (we are the final user) so it is a purely logistical and time issue.
I think I can review and test the code to close this module ASAP

I have migrated this module to version 12.0, there is an open PR #151. I have asked you because I have the code already migrated (there are few changes to do) but after that I have verified that you already had an open PR. If you are busy I can open a PR if you want, of course 😄

Of course, no problem. I'm obviously very busy with 12.0 migration :)

bjeficent · 2019-01-31T12:21:02Z

Hi @meigallodixital, are you still working on this?

We are considering migrating to version 12.0 now. I have been testing it in January. We notice that it seems that the development is slightly more agile in this version. Version 11.0 took a lot more time to migrate many modules than what is taking 12.0.
We do not want this to be seen as a complaint, but here I am only myself for development and implementation (we are the final user) so it is a purely logistical and time issue.
I think I can review and test the code to close this module ASAP

I have migrated this module to version 12.0, there is an open PR #151. I have asked you because I have the code already migrated (there are few changes to do) but after that I have verified that you already had an open PR. If you are busy I can open a PR if you want, of course smile

Of course, no problem. I'm obviously very busy with 12.0 migration :)

Perfect, thanks for the quick answer

github-actions · 2021-12-05T12:22:26Z

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

JordiBForgeFlow and others added 20 commits July 10, 2018 09:32

stock_operating_unit

0008262

flake8 issues

7016c65

flake 8

82a17be

flake 8

2f94af1

update contributors

ebdee4b

code style

c8fbcd7

constraint that checks the OU in the picking matches the one in the move

64e0dee

the operating unit in pickings should derive from the picking type

0aa4a1c

travis issues

bf8fe90

travis issues and test stock picking

e0eea69

test stock security according picking 1 in test_stock_picking

2ac1bfc

Update operating units of previous locations

45c6f65

lint check operating_unit_id readonly in the picking

8a43745

Correct error message and xml files

4fbb975

* Replace <openerp> and <data> elements by <odoo> * Remove spaces in strings introduced because of \ * Remove exclamation points in error messages * Remove most of the \ where it can be replaced by parenthesis

[MIG] stock_operating_unit to v10.0

e57b5b9

[FIX] stock_operating_unit: correct constrain function, avoid error o…

ddf3f16

…n pickings

[FIX]onchange does not work with readonly fields

02e070f

[FIX]stock.move._check_stock_move_operating_unit

da1aa54

[FIX]internal locations should consider all locations but customer or…

7f02f02

… suppliers

[MIG]stock_operating_unit to v11

6dce410

AaronHForgeFlow reviewed Jul 10, 2018

View reviewed changes

AaronHForgeFlow reviewed Jul 12, 2018

View reviewed changes

nikul-serpentcs reviewed Aug 30, 2018

View reviewed changes

pedrobaeza mentioned this pull request Nov 28, 2018

Migration to version 11.0 #94

Closed

11 tasks

meigallodixital closed this Jan 31, 2019

meigallodixital reopened this Jan 31, 2019

bjeficent mentioned this pull request Jan 31, 2019

[11.0] [MIG] stock_operating_unit #164

Merged

max3903 added this to the 11.0 milestone Dec 27, 2019

github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Dec 5, 2021

github-actions bot closed this Jan 9, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[11.0][WIP] stock_operating_unit #132

[11.0][WIP] stock_operating_unit #132

meigallodixital commented Jul 9, 2018

AaronHForgeFlow commented Jul 9, 2018

meigallodixital commented Jul 9, 2018

AaronHForgeFlow commented Jul 9, 2018

meigallodixital commented Jul 9, 2018 •

edited

Loading

AaronHForgeFlow commented Jul 10, 2018

AaronHForgeFlow commented Jul 10, 2018

meigallodixital commented Jul 10, 2018

AaronHForgeFlow commented Jul 10, 2018

meigallodixital commented Jul 10, 2018

AaronHForgeFlow commented Jul 10, 2018

meigallodixital commented Jul 10, 2018

AaronHForgeFlow Jul 10, 2018

meigallodixital Jul 12, 2018 •

edited

Loading

AaronHForgeFlow Jul 12, 2018

meigallodixital Jul 12, 2018 •

edited

Loading

AaronHForgeFlow commented Jul 12, 2018

nikul-serpentcs Aug 30, 2018 •

edited

Loading

meigallodixital Sep 3, 2018

bjeficent commented Jan 31, 2019

meigallodixital commented Jan 31, 2019

bjeficent commented Jan 31, 2019

meigallodixital commented Jan 31, 2019

meigallodixital commented Jan 31, 2019

bjeficent commented Jan 31, 2019

github-actions bot commented Dec 5, 2021

[11.0][WIP] stock_operating_unit #132

[11.0][WIP] stock_operating_unit #132

Conversation

meigallodixital commented Jul 9, 2018

AaronHForgeFlow commented Jul 9, 2018

meigallodixital commented Jul 9, 2018

AaronHForgeFlow commented Jul 9, 2018

meigallodixital commented Jul 9, 2018 • edited Loading

AaronHForgeFlow commented Jul 10, 2018

AaronHForgeFlow commented Jul 10, 2018

meigallodixital commented Jul 10, 2018

AaronHForgeFlow commented Jul 10, 2018

meigallodixital commented Jul 10, 2018

AaronHForgeFlow commented Jul 10, 2018

meigallodixital commented Jul 10, 2018

AaronHForgeFlow Jul 10, 2018

Choose a reason for hiding this comment

meigallodixital Jul 12, 2018 • edited Loading

Choose a reason for hiding this comment

AaronHForgeFlow Jul 12, 2018

Choose a reason for hiding this comment

meigallodixital Jul 12, 2018 • edited Loading

Choose a reason for hiding this comment

AaronHForgeFlow commented Jul 12, 2018

nikul-serpentcs Aug 30, 2018 • edited Loading

Choose a reason for hiding this comment

meigallodixital Sep 3, 2018

Choose a reason for hiding this comment

bjeficent commented Jan 31, 2019

meigallodixital commented Jan 31, 2019

bjeficent commented Jan 31, 2019

meigallodixital commented Jan 31, 2019

meigallodixital commented Jan 31, 2019

bjeficent commented Jan 31, 2019

github-actions bot commented Dec 5, 2021

meigallodixital commented Jul 9, 2018 •

edited

Loading

meigallodixital Jul 12, 2018 •

edited

Loading

meigallodixital Jul 12, 2018 •

edited

Loading

nikul-serpentcs Aug 30, 2018 •

edited

Loading