OCA / connector-jira

GNU Affero General Public License v3.0
21 stars 45 forks source link

[12.0] connector_jira: extra features #7

Closed alexey-pelykh closed 5 years ago

alexey-pelykh commented 5 years ago

@guewen @simahawk couple of questions about this module:

guewen commented 5 years ago

Odoo-to-Jira sync of tasks on creation was not implemented because ...?

Only because we didn't really need it / budget.

Restricting editing/creation of Odoo tasks on linked projects was not implemented because ...?

Same

alexey-pelykh commented 5 years ago

@guewen thanks for your swift reply! Then once v12 is reviewed and merged, I'm into making new features as I need them as hell

alexey-pelykh commented 5 years ago

@guewen one more question, planned_hours on tasks in not imported due to same reason?

guewen commented 5 years ago

@guewen one more question, planned_hours on tasks in not imported due to same reason?

Yep

alexey-pelykh commented 5 years ago

PRs are pending, closing. If anyone have other ideas what to import, feel free to chime in.

iledarn commented 2 years ago

@alexey-pelykh , why did you need Restricting editing/creation of Odoo tasks on linked projects This feature is undesirable in my case btw

iledarn commented 2 years ago

How these two can be implemented both? I do mean that if we would have Odoo-to-Jira sync (bi-directional connector) then we definitely shouldn't restrict anything

iledarn commented 2 years ago

Side note: I myself prefer to have a single binding (one Odoo instance to one Jira instance, one project to one project) bi-directional connector. I wonder about what are the benefits of having such design with "multi-bindings" projects at all

alexey-pelykh commented 2 years ago

why did you need Restricting editing/creation of Odoo tasks on linked projects

@iledarn in my case, Odoo instance was a complete Jira-To-Odoo mirror, updated via sync regularly, so making changes in Odoo (altering tasks, projects, or creating new tasks in mirrored projects) was confusing for the end-users unless there would've been a bidirectional connector. But since there wasn't one (and there isn't one still) - for unidirectional mirroring, the receiving end of connector should be locked for editing to avoid data loss.