[MIG][9.0][auth_supplier] Migrate. #434
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Update to v9, with mostly cosmetic changes.
|
👍 thanks |
| @@ -1,6 +1,5 @@ | |||
| <?xml version="1.0" encoding="utf-8"?> | |||
| <openerp> | |||
There was a problem hiding this comment.
Change this to to use the new "cool" tag (and to avoid the need to change it when the other tag will be deprecated)
|
👍 |
| Configuration | ||
| ============= | ||
|
|
||
| * To enable users to create accounts: |
There was a problem hiding this comment.
You can include here that "Developer mode" should be activated first to have access to "Technical features".
| To use this module, you need to: | ||
|
|
||
| * Log out. | ||
| * In home page, press *Sign in*. |
There was a problem hiding this comment.
s/Sign in/Sign up/ (tested on runbot)
|
A little remark, maybe mention it as a Known issue, but 👍 |
yajo
added a commit
to Tecnativa/server-tools
that referenced
this pull request
Jun 3, 2016
The whole purpose of this module was to be able to separate a customer and a supplier portals. Given the status of the upstream implementations of portals, it is not possible to have a supplier portal without portal permissions. Thus, it would be required to make the group this module was creating inherit from `base.group_portal`, which would give suppliers access to all customers portal. As such, that group becomes useless. From now on, this distinction should be made with simply checking if `user.customer` or `user.supplier` is `True`. To allow that, I'm implementing what was discussed at OCA#434 (diff). Tests had to be removed because odoo/odoo#12237 makes the created record to disappear, so there's no way to actually check the created user was created with customer or supplier flag on.
yajo
added a commit
to Tecnativa/server-tools
that referenced
this pull request
Jun 3, 2016
The whole purpose of this module was to be able to separate a customer and a supplier portals. Given the status of the upstream implementations of portals, it is not possible to have a supplier portal without portal permissions. Thus, it would be required to make the group this module was creating inherit from `base.group_portal`, which would give suppliers access to all customers portal. As such, that group becomes useless. From now on, this distinction should be made with simply checking if `user.customer` or `user.supplier` is `True`. To allow that, I'm implementing what was discussed at OCA#434 (diff). Tests had to be removed because odoo/odoo#12237 makes the created record to disappear, so there's no way to actually check the created user was created with customer or supplier flag on.
yajo
added a commit
to Tecnativa/server-tools
that referenced
this pull request
Jun 3, 2016
The whole purpose of this module was to be able to separate a customer and a supplier portals. Given the status of the upstream implementations of portals, it is not possible to have a supplier portal without portal permissions. Thus, it would be required to make the group this module was creating inherit from `base.group_portal`, which would give suppliers access to all customers portal. As such, that group becomes useless. From now on, this distinction should be made with simply checking if `user.customer` or `user.supplier` is `True`. This means no additional problems since `ir.rule` domains can use the `user` variable. To allow that, I'm implementing what was discussed at OCA#434 (diff). Tests had to be removed because odoo/odoo#12237 makes the created record to disappear, so there's no way to actually check the created user was created with customer or supplier flag on.
JosDeGraeve
pushed a commit
to apertoso/server-tools
that referenced
this pull request
Jun 13, 2016
* [ADD] auth_supplier: New Module. * [ADD] auth_supplier: New Module. * [FIX] auth_supplier: Change author order. * [MIG][9.0][auth_supplier] Migrate. Update to v9, with mostly cosmetic changes. * Update XML tags. * Inform about the need to have technical features enabled. * Don't assume website is installed. * Add known issue
yajo
added a commit
to Tecnativa/server-tools
that referenced
this pull request
Jun 28, 2016
The whole purpose of this module was to be able to separate a customer and a supplier portals. Given the status of the upstream implementations of portals, it is not possible to have a supplier portal without portal permissions. Thus, it would be required to make the group this module was creating inherit from `base.group_portal`, which would give suppliers access to all customers portal. As such, that group becomes useless. From now on, this distinction should be made with simply checking if `user.customer` or `user.supplier` is `True`. This means no additional problems since `ir.rule` domains can use the `user` variable. To allow that, I'm implementing what was discussed at OCA#434 (diff). Tests had to be removed because odoo/odoo#12237 makes the created record to disappear, so there's no way to actually check the created user was created with customer or supplier flag on.
JayVora-SerpentCS
pushed a commit
to JayVora-SerpentCS/server-tools
that referenced
this pull request
Sep 12, 2016
* [ADD] auth_supplier: New Module. * [ADD] auth_supplier: New Module. * [FIX] auth_supplier: Change author order. * [MIG][9.0][auth_supplier] Migrate. Update to v9, with mostly cosmetic changes. * Update XML tags. * Inform about the need to have technical features enabled. * Don't assume website is installed. * Add known issue
JayVora-SerpentCS
pushed a commit
to JayVora-SerpentCS/server-tools
that referenced
this pull request
Sep 12, 2016
The whole purpose of this module was to be able to separate a customer and a supplier portals. Given the status of the upstream implementations of portals, it is not possible to have a supplier portal without portal permissions. Thus, it would be required to make the group this module was creating inherit from `base.group_portal`, which would give suppliers access to all customers portal. As such, that group becomes useless. From now on, this distinction should be made with simply checking if `user.customer` or `user.supplier` is `True`. This means no additional problems since `ir.rule` domains can use the `user` variable. To allow that, I'm implementing what was discussed at OCA#434 (diff). Tests had to be removed because odoo/odoo#12237 makes the created record to disappear, so there's no way to actually check the created user was created with customer or supplier flag on.
dsolanki-initos
pushed a commit
to initOS/server-tools
that referenced
this pull request
Feb 14, 2020
* [ADD] auth_supplier: New Module. * [ADD] auth_supplier: New Module. * [FIX] auth_supplier: Change author order. * [MIG][9.0][auth_supplier] Migrate. Update to v9, with mostly cosmetic changes. * Update XML tags. * Inform about the need to have technical features enabled. * Don't assume website is installed. * Add known issue
dsolanki-initos
pushed a commit
to initOS/server-tools
that referenced
this pull request
Feb 14, 2020
The whole purpose of this module was to be able to separate a customer and a supplier portals. Given the status of the upstream implementations of portals, it is not possible to have a supplier portal without portal permissions. Thus, it would be required to make the group this module was creating inherit from `base.group_portal`, which would give suppliers access to all customers portal. As such, that group becomes useless. From now on, this distinction should be made with simply checking if `user.customer` or `user.supplier` is `True`. This means no additional problems since `ir.rule` domains can use the `user` variable. To allow that, I'm implementing what was discussed at OCA#434 (diff). Tests had to be removed because odoo/odoo#12237 makes the created record to disappear, so there's no way to actually check the created user was created with customer or supplier flag on.
dsolanki-initos
pushed a commit
to initOS/server-tools
that referenced
this pull request
Dec 16, 2020
* [ADD] auth_supplier: New Module. * [ADD] auth_supplier: New Module. * [FIX] auth_supplier: Change author order. * [MIG][9.0][auth_supplier] Migrate. Update to v9, with mostly cosmetic changes. * Update XML tags. * Inform about the need to have technical features enabled. * Don't assume website is installed. * Add known issue
dsolanki-initos
pushed a commit
to initOS/server-tools
that referenced
this pull request
Dec 16, 2020
The whole purpose of this module was to be able to separate a customer and a supplier portals. Given the status of the upstream implementations of portals, it is not possible to have a supplier portal without portal permissions. Thus, it would be required to make the group this module was creating inherit from `base.group_portal`, which would give suppliers access to all customers portal. As such, that group becomes useless. From now on, this distinction should be made with simply checking if `user.customer` or `user.supplier` is `True`. This means no additional problems since `ir.rule` domains can use the `user` variable. To allow that, I'm implementing what was discussed at OCA#434 (diff). Tests had to be removed because odoo/odoo#12237 makes the created record to disappear, so there's no way to actually check the created user was created with customer or supplier flag on.
SiesslPhillip
pushed a commit
to grueneerde/OCA-server-tools
that referenced
this pull request
Nov 20, 2024
Syncing from upstream OCA/server-tools (10.0)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update to v9, with mostly cosmetic changes.
@Tecnativa #271