Skip to content

[ADD][18.0] base_iso7010#236

Open
bosd wants to merge 1 commit intoOCA:18.0from
bosd:18.0-base_iso7010
Open

[ADD][18.0] base_iso7010#236
bosd wants to merge 1 commit intoOCA:18.0from
bosd:18.0-base_iso7010

Conversation

@bosd
Copy link
Contributor

@bosd bosd commented May 5, 2025

Base module to allow usage of ISO7010 symbols in odoo on models or documents.

@bosd bosd force-pushed the 18.0-base_iso7010 branch from cd2fbba to 6b3951b Compare June 4, 2025 17:25
@bosd bosd force-pushed the 18.0-base_iso7010 branch from 6b3951b to 8321f35 Compare June 4, 2025 17:27
Copy link

@LoisRForgeFlow LoisRForgeFlow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@diggy128
Copy link

Just a comment here.

I've created a similar module that creates a "sign" module with mostly the same usage.

There is also a category field where ISO7010 signs are in.
Using this approach allows having ALL signs in one model eg. ISO 3864, ISO 7001, and a few GHS with a kanban view.

Maybe following a more generic approach could lead to better adaptation?

@bosd
Copy link
Contributor Author

bosd commented Sep 15, 2025

Maybe following a more generic approach could lead to better adaptation?

Ooh, yeah. I am open for ideas. The word sign brings up associations with the signature module of odoo.

@diggy128
Copy link

Ooh, yeah. I am open for ideas. The word sign brings up associations with the signature module of odoo.

True. I don't like it either. Maybe signs or signage? (I prefer the second because the first one is in plural that should not be used in model names).

On an additional point. I've placed the menu in Knowledge since, for the most part, these signs will be in context to ISO 45001 and are part of the organization's information. What do you think?

@diggy128
Copy link

diggy128 commented Oct 1, 2025

Hello @bosd
I'm currently refactoring the module I mentioned in my previous message to cater for more use cases.
Would you like to merge efforts and collaborate?

@bosd
Copy link
Contributor Author

bosd commented Oct 5, 2025

@diggy128 Im open to collab.
But idk how to proceed with this. Out of the names I prefer signage as well.
But the scope of this module is quite broad. It could be used for adding icons into work instructions. Quality handbooks, Safety handbooks, forms, guidelines.
In the context of ISO45001 might be related to the work in https://github.com/OCA/management-system

The scope of signage module would be much broader. As signs for ADR products would also fall in that category.

Using this approach allows having ALL signs in one model eg. ISO 3864, ISO 7001, and a few GHS with a kanban view.

I had to lookup the iso 3864. Looks very cool, that users could design their own signage according to this standard.

As the scope get's very broad quickly, IMO it is best to minimize it.
I only needed the symbols to be added on some reports. (Custom Manufacturing order instructions). The client is not using the quality management system (of oca or enterprise).
Building a "signage" designer in odoo to let users create their own ISO 3864 sign might be a huge undertaking. Oou of scope of my current project.

Even the ISO7001 is already quite huge. As of now I only made the PR for the mandatory signs (blue circle icons).
It was my intention to add pr's for the other icons as well. (but did not get to it yet.)
Long stoy short. I think I'm quite happy with the structure, to have the modules categorized by ISO standard and symbol type. So one can selectively install what they need. (w/o having a heavy dependenncy on other modules)
A common parent module could help. And some glue modules.

One of the missing pieces in my opinion is the ability to add these icons in a user friendly way to an html field.
e.g. create a tab (or more) next to the icon tab in the screenshot below:
image

So end users could easily add those icons anywhere they like.

Where do you see overlap and possibilities to collab?

@diggy128
Copy link

diggy128 commented Oct 6, 2025

@diggy128 Im open to collab. But idk how to proceed with this. Out of the names I prefer signage as well. But the scope of this module is quite broad. It could be used for adding icons into work instructions. Quality handbooks, Safety handbooks, forms, guidelines. In the context of ISO45001 might be related to the work in https://github.com/OCA/management-system

The scope of signage module would be much broader. As signs for ADR products would also fall in that category.

That was what I had in mind.
Instead of having various modules per scope and creating multiple fields:
e.g. for workcenter: safety_symbol_ids for ISO7010, adr_symbol_ids for ADR, etc..
Have:
for workcenter: symbol_ids
and in symbol model have a many2one category field that will have ISO7010, ISO3864, ADR, GHS

This will have the following benefits:

  1. Single model for ALL types of signs (whether standardized or custom)
  2. Single view for all relative signs. e.g. from a workcenter you will see ALL signs (warnings, obligations, ADR, GHS, etc.)
  3. Ιmport standardized signs for system without requiring to install additional modules. Just create a new sign category (eg. ISO7010, GHS, ADR, etc.)
  4. No dependence whatsoever to any other module. Links to additional models will be with glue modules (just like you did)
  5. Easier to do GAP analysis for missing signs (regardless of their type).
  6. Easier to import localized signs (check the images at the end) as not extra module and model will be needed.

As the scope get's very broad quickly, IMO it is best to minimize it. I only needed the symbols to be added on some reports. (Custom Manufacturing order instructions). The client is not using the quality management system (of oca or enterprise). Building a "signage" designer in odoo to let users create their own ISO 3864 sign might be a huge undertaking. Oou of scope of my current project.

This is simpler that you might think. I've implemented this by assigning foreground and background color for each sign category and creating a report that prints the image (if set in the field) and the descriptive text after that. Have a look at the Obligation sign.pdf for a custom obligation sign.
This also allows to have custom signs linked through glue models.
The designer just has to play with the font size to fit in the report depending on the text length. We already do that and print custom signs in-house, currently migrating ALL signs to comply to ISO3864.

Even the ISO7001 is already quite huge. As of now I only made the PR for the mandatory signs (blue circle icons). It was my intention to add pr's for the other icons as well. (but did not get to it yet.) Long stoy short. I think I'm quite happy with the structure, to have the modules categorized by ISO standard and symbol type. So one can selectively install what they need. (w/o having a heavy dependency on other modules) A common parent module could help. And some glue modules.

See point 3 above. With the current structure, any sign not mentioned in ISO7010 will require a new module with a new model, view, action, etc. The same goes for all glue modules.

One of the missing pieces in my opinion is the ability to add these icons in a user friendly way to an html field. e.g. create a tab (or more) next to the icon tab in the screenshot below:

I did try this in the first versions of my module but it had bad outcomes. Symbols were resized, cropped and their use could not be controlled so I opted to have a stricter designing procedure where each sign is designed and assigned ONLY by specific users (in our case the management system administrator).

To put things into perspective here are a few screenshots from my module:
All signs view
Screenshot_20251006_151828

Sign form view
Screenshot_20251006_152513

Sign placement in maintenance.equipment
Screenshot_20251006_153546

@bosd
Copy link
Contributor Author

bosd commented Jan 24, 2026

This will have the following benefits:

1. Single model for ALL types of signs (whether standardized or custom)

2. Single view for all relative signs. e.g. from a workcenter you will see ALL signs (warnings, obligations, ADR, GHS, etc.)

3. Ιmport standardized signs for system without requiring to install additional modules. Just create a new sign category (eg. ISO7010, GHS, ADR, etc.)

4. No dependence whatsoever to any other module. Links to additional models will be with glue modules (just like you did)

5. Easier to do GAP analysis for missing signs (regardless of their type).

6. Easier to import localized signs (check the images at the end) as not extra module and model will be needed.

Sound very interesting!
Point 3 seems to be a bit of the oca way. One's db, can stay lean, in my use cuse, we only need the mandatory signs. No need to import a lot f records and images for other types.

The signage designer is a nice feature!!

Can you open a PR to glue these modules together?

@diggy128
Copy link

@bosd
Take a look at [18.0] [ADD] signage#582
over at knowledge repo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants