States "genericity"

[trasher]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes

Should be more or less OK.
No SO is working.
Naming is probably not OK everywhere.

Since I'm not sure the way I've chosen is OK, I don't waste more time on that for now.

[trasher]

ping @cedric-anne @orthagh

As said already on internal channel, I need a first validation/talk on this one. Main problem will be search options; I do not even know if current system can handle current PR.
Also, if one of you see another solution to make states generic, I'll be happy to think about it.

[cconard96]

Commit to support the new state visibilties in the new API:
cconard96@232bc69

This info for states can only be seen through GraphQL at the moment (POST request at /api.php/GraphQL).
Sample GraphQL JSON body to test this:

query {
    Computer(limit: 10) {
        id
        status {
            name
            visibilities {
                computer
                monitor
            }
        }
    }
}

[trasher]

I've never been able to use API; if tests are OK, that's OK for me (need someone else to do the review).

[cconard96]

I've never been able to use API; if tests are OK, that's OK for me (need someone else to do the review).

Is there a technical issue with it that I need to check/fix?

[trasher]

Is there a technical issue with it that I need to check/fix?

No :) I just cannot test API side if any state change are working.

[trasher]

I've fixed all remaining cases I saw; should be OK now.

[cedric-anne]

I pushed a commit to check that all items having the states_id field are present in $CFG_GLPI['state_types'].

1. There are 2 exceptions: DeviceGeneric and DeviceSensor have this type, in contrary to other devices. IMHO, we should drop this field. Indeed, the state should be set on Item_DeviceGeneric and Item_DeviceSensor items, not on the "model" itself.

@orthagh @trasher Are you OK to remove this field?

2. Now Item_Device* will have a filtered list of status. Until now, the list was not filtered, meaning that existing Item_Device* may already be assigne to some statuses that will no longer be available. There are multiple solutions to this:
   1. add a warning to tell to the administrator that states visibility should be configured manually;
   2. make a migration to make the already used states visible for the devices that areay use them;
   3. make a migration to make the existing states visible for all devices.

I think the first solution is sufficient, as an already define status will still be displayed in the dropdown:

@orthagh @trasher What is your opinion on this point ?

[trasher]

1. There are 2 exceptions: `DeviceGeneric` and `DeviceSensor` have this type, in contrary to other devices. IMHO, we should drop this field. Indeed, the state should be set on `Item_DeviceGeneric` and `Item_DeviceSensor` items, not on the "model" itself.
   @orthagh @trasher Are you OK to remove this field?

Yes; it has nothing to do in main device table.

2. Now `Item_Device*` will have a filtered list of status. Until now, the list was not filtered, meaning that existing `Item_Device*` may already be assigne to some statuses that will no longer be available. There are multiple solutions to this:


1. add a warning to tell to the administrator that states visibility should be configured manually;

2. make a migration to make the already used states visible for the devices that areay use them;

3. make a migration to make the existing states visible for all devices.

I think the first solution is sufficient, as an already define status will still be displayed in the dropdown:

@orthagh @trasher What is your opinion on this point ?

I guess it would be preferable not to change data if possible. So, if just keeping values as-is does not break any feature; I guess it's enough.