SINAPS : acquisition couldn't be sent because primary affectation isn't set

Description

After creating an account, FD could send contact method juste after

Distribution Name and Version

Debian Stretch

FusionDirectory Version

fusiondirectory 1.3-2~jenkinsbuild96

Plugin with the defect

ii fusiondirectory-plugin-sinaps 1.3-2~jenkinsbuild96

PHP version used

php7

Origin of php packages

from debian repos

Steps to Reproduce

1. from sinaps, send a new user
2. check if supannEntiteAffectationPrincipale is filled

Expected behavior:

both supannEntiteAffectationPrincipale field and supannEntiteAffectation should be filled

Actual behavior:

only supannEntiteAffectation is filled

Reproduces how often:

It seems that that is not always the case. I'm note sure that is in 100%

Additional Information

if no affectation are filled, xml sent to SINAPS in order to send contact method has no success to be integrated.

assigned to @MCMic

changed title from SINAPS : acquisition couldn't be sent because primaryu affectation isn't set to SINAPS : acquisition couldn't be sent because primary affectation isn't set

added PJ1803-0195 label

added plugin-sinaps label

added 5m of time spent at 2019-02-12

hello @gallak,

can you provide the xml related to this possible bug

Indeed if supannEntiteAffectationPrincipale is not filled, which is currently the case for PRA, the role is not filled in the acquisition XML.

I can easily set the role in all cases, but should supannEntiteAffectationPrincipale still be set in personne/rattachements/rattachement/identifiantStructureDeRattachement for PR? Because that is not what is sent by Sinaps in this field.

after some research correct sinaps field to take are the following :

• PRA : rattachements>rattachement>roles>role>typeRole = EXT > externe > identifiantStructureInterne
• PR : rattachements>rattachement>roles>role>typeRole = PR > personneRessource > affectations > affectation> identifiantStructureInterne

I waiting for confirmation about the mono ou multivaluated aspect ( quotite tag in PR)

I waiting for confirmation about the mono ou multivaluated aspect ( quotite tag in PR)

@gallak Any news?

It's seems be the case, this field is multivalued. In this case, all affectation have to be read and set in supannEntiteAffectation. The affectation with the biggest "quotite" should be the supannEntiteAffectationPrincipale. In case of 50/50 quotite, take first one.

@gallak So, if I understand correctly you are talking about diffusion here, not acquisition?

Can you explain what "quotite" is and give an example?

And for acquisition, maybe we should not put anything in personne/rattachements/rattachement/identifiantStructureDeRattachement ?

added 30m of time spent at 2019-03-12

Yes you are right , because the diffusion (SINAPS => FD) wasn't complete (no supannEntiteAffectationPrincipale), the diffusion failed ( because diffusion must contain affectation).

Quotite is the amount of work per affectation.

Extract of "quotite"

                      <affectation>
                        <quotite>100</quotite>
                        <identifiantStructureInterne>0456d80b-6baa-41c7-8888-16fac2ae1d98</identifiantStructureInterne>
                        <typeStructure>ORG</typeStructure>
                        <sousTypeStructure>{SUPANN}S310</sousTypeStructure>
                        <natureStructure>UR</natureStructure>
                        <dateDebut>2018-12-14</dateDebut>
                        <referenceCroisee>
                          <identifiantSINAPS>1a1d21a9-efce-4354-ae05-3a64c9241578</identifiantSINAPS>
                          <identifiantsExternes>
                            <identifiantExterne>50018800</identifiantExterne>
                            <identifiantApplication>SAP</identifiantApplication>
                          </identifiantsExternes>
                          <identifiantsExternes>
                            <identifiantExterne>0456d80b-6baa-41c7-8888-16fac2ae1d98</identifiantExterne>
                            <identifiantApplication>PASSPORT</identifiantApplication>
                          </identifiantsExternes>
                        </referenceCroisee>
                      </affectation>
                    </affectations>

for acquisition identifiantStructureDeRattachement seems to be mandatory

changed milestone to %FusionDirectory 1.3.1

changed due date to May 09, 2019

mentioned in commit 4ecf6baf

mentioned in commit fdb837dc

mentioned in commit d041fb4d