Multiple groups for assets

[cconard96]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	YES
Deprecations?	no
Tests pass?	NO
Fixed tickets	!30462

For assets, the groups_id and groups_id_tech fields are changed to allow multiple selections.

[cconard96]

Currently broken and I am not making any progress to resolve:

• Group search option for ReservationItem - DB schema is different between itemtypes that have one vs multiple groups, so the search option isn't the same for everything anymore.
• Group/Group Tech search options for AllAssets - Same as above
• Metacriteria Group search options for assets with multiple groups - Same as above

[cedric-anne]

Currently broken and I am not making any progress to resolve:

• Group search option for ReservationItem - DB schema is different between itemtypes that have one vs multiple groups, so the search option isn't the same for everything anymore.
• Group/Group Tech search options for AllAssets - Same as above
• Metacriteria Group search options for assets with multiple groups - Same as above

What are these itemtypes that have only one group?

[cconard96]

What are these itemtypes that have only one group?

Rack, Certificate, Appliance, Item_DeviceSimcard, Line, SoftwareLicense, Unmanaged at least based on the related arrays in inc/define.php. Then, whatever plugins add to these arrays (I don't know which plugins the client is using currently).

[cedric-anne]

What are these itemtypes that have only one group?

Rack, Certificate, Appliance, Item_DeviceSimcard, Line, SoftwareLicense, Unmanaged at least based on the related arrays in inc/define.php. Then, whatever plugins add to these arrays (I don't know which plugins the client is using currently).

IMHO, All items defined in the linkgroup_types and linkgroup_tech_types config entries should be linkable to multiple groups. All the class your are listing here may probably declared in these config entries, if they are not yet.

[cconard96]

In addition to my previous comment, these itemtypes have groups_id or groups_id_tech columns and may be relevant to issues with this PR or issues in the future:

• Cluster
• DatabaseInstance
• DomainRecord
• Domain
• Enclosure
• PassiveDCEquipment
• PDU

[cconard96]

IMHO, All items defined in the linkgroup_types and linkgroup_tech_types config entries should be linkable to multiple groups. All the class your are listing here may probably declared in these config entries, if they are not yet.

That means expanding potentially both the new Read/Update Assigned rights and multiple-groups feature beyond assets which is beyond the scope of the developments that was agreed to.

[cedric-anne]

I still think it would be better to apply this change to all the classes that are present in the linkgroup_types and the linkgroup_tech_types configurations.

1. It would make this behaviour consistant accross all assets.
2. It would probably give the ability to validate that the trait methods are correctly executed by doing some tests that loops on all these configured types.

@orthagh @trasher , your opinion on this?

[orthagh]

I still think it would be better to apply this change to all the classes that are present in the linkgroup_types and the linkgroup_tech_types configurations.

I agree.
As discussed with @cedric-anne in Mattermost, the initial selection must be due to the assets profile page.
For the moment, I think we should extend the fields changes to a larger selection (good example: Rack)
The whole "Management" tab of profiles could be adapted as "Assets" tab.
For the lines where the split of right is not relevant (infocom ?), maybe we can disable the relative checkbox.

For things where a profile change is complex, still make the multiple fields. We can manage the rest afterward probably.
Everything considered as an asset should behave the same with these fields.
Plugins are another matter, let's leave it aside for the moment.

That means expanding potentially both the new Read/Update Assigned rights and multiple-groups feature beyond assets which is beyond the scope of the developments that was agreed to.

Do this represent a big work @cconard96 ?
I agree Wuerth has not ordered this, but we will need to maintain the dev after.

[cconard96]

I agree. As discussed with @cedric-anne in Mattermost, the initial selection must be due to the assets profile page. For the moment, I think we should extend the fields changes to a larger selection (good example: Rack) The whole "Management" tab of profiles could be adapted as "Assets" tab.

Some things on the Management tab will need to remain. Suppliers, contacts and infocom aren't assets. I'm not sure contracts are either. Would that mean changing which menu the types are under too so that it matches?

For the lines where the split of right is not relevant (infocom ?), maybe we can disable the relative checkbox.

I don't know what this is referring to.

For things where a profile change is complex, still make the multiple fields. We can manage the rest afterward probably. Everything considered as an asset should behave the same with these fields. Plugins are another matter, let's leave it aside for the moment.

That means expanding potentially both the new Read/Update Assigned rights and multiple-groups feature beyond assets which is beyond the scope of the developments that was agreed to.

Do this represent a big work @cconard96 ? I agree Wuerth has not ordered this, but we will need to maintain the dev after.

Depends on what we decide is an asset, I think.

[cedric-anne]

I just rebased to include modifications made in #17021. Maybe some tests will be broken.

[cedric-anne]

I put the PR back to draft, waiting for the customer feedback.

[cedric-anne]

The customer has validated the feature.

I just rebased the branch to fix conflicts.