Incompletely created organizations #150
Comments
|
I doubt this is a Datacore problem, it's most probably rather on portal side. A few ideas:
| DEBUG| 17:57:06.989 | org.oasis_eu.portal.services.dc.organization.DCOrganizationService - It doesn't exist in DC Doing a datacore.saveResource() with : org,DCOrganization{legal_name='testCreaOrga1755', sector_type='COMPANY', country_uri='http://data.ozwillo.com/dc/type/geocofr:Pays_0/FR', lang='fr', org_type='null', tax_reg_num='testCreaOrga1755'} => indeed there should be a country, and an odisp:name should have been computed out of all that, but I can't see what "other fields" would have been lost ?
(I don't know at all if this 409 Conflict error is related or not. But indeed, not properly handling a 409 (by re-attempting POST/PUT) could trigger such a problem, IF the Resource org were to be written in two POST/PUT requests, which it should not, though maybe the previous portal code or even the react front is badly written and do 2 requests) |
|
When trying to modify the same org with the same user: java.lang.NullPointerException org.oasis_eu.portal.services.dc.organization.DCOrganizationService.setDCIdOrganization(DCOrganizationService.java:337) org.oasis_eu.portal.services.dc.organization.OrganizationService.update(OrganizationService.java:147) org.oasis_eu.portal.front.my.network.NetworkAJAXServices.updateDCOrganization(NetworkAJAXServices.java:146) because (as a consequence of above) there is no country (to take an acronym of): |
Maybe. I don't know (and that's why I did not label this issue as a bug).
Yes, I saw them. I have even put them in my first comment. This is a log I've added to see what was sent to the DC and you only see here the fields I added to the log (and country and odisp:name are not one of them). Other lost fields are the fields required to create an organization (street name, NAF code, ...). I'll add them to the log trace.
Yes, org_type is also null for a correctly created organization.
Ok, I'll try that.
If it was the case, I would see the two calls in the portal logs. And I don't.
Yes, I noticed that. But, as you said, that's just a consequence of the creation problem. |
|
@OzBruno got a similar problem this morning : On the creation request, the DC answers that it already exists. But I don't get why, when we search for it juste before asking for its creation, we have no results found. When I try in the DC playground :
|
|
This last request returns no result because the organization has no country since it is indeed incomplete. |
|
Finally, I was able to reproduce the problem in production with some (but not all) of my test accounts (and also with fresh new accounts). I was not able to reproduce it in pre-production, nor in development (even with fresh new accounts). I attached a debugger to the portal and saw no double creation request. Here is what the portal sent : And the response received from the DC : As it is not reproducible with all user accounts, maybe it has something to do with some user profile data (but which ?) ? |
|
OK, it seems the code of the Portal itself is alright. So the problem is either in the portal REST layer (when the Portal DCResource is converted to JSON) or in the Datacore. As you guess, I incline to the former, especially if it has to do with profile data. But let's debug that together anyway. |
|
I've just made an organization's creation test and I still have the problem with the geo-related fields not being persisted : |
|
PS : but it is still OK with my "old" account that did not had the problem |
|
Could you try again now the "modify" case ? I've just found another problematic case, and tried something simpler that solves it (however, the "create" case should still be a problem with adrpostci fields). |
|
I've been able to reproduce most of these problems. |
|
Now that this new fix has been deployed in production, can you confirm it is OK ? |
|
This use case is OK in prod (tested by @OzBruno and me). But we have a problem when « acquiring » an existing organization (I gonna create a new issue for it). |
|
I've encountered again the problem with a different behaviour : I've created organisations on "My Network", coming back later I can modify the information like the address, but the org:country is still not stored in the DC whereas the adrpost:country is stored. And this prevents users to install some application such as Agrilocal. |
|
It works alright for my test user in the Playground both for creation and modification: So it is probably not the same problem as before but another one. Indeed, looking again at what the portal sends (log provided by @bobeal ): => indeed we can see adrpost fields, that the Datacore unduly ate before. But we can't see the org:country field. Therefore it is a portal problem this time, see ozwillo/ozwillo-portal#363 . |
Hi,
We encounter a problem when creating organizations :
Logs related to the organization testCreaOrga1755 :
The creation seems to have been working fine, the organization has a DC id and it is then created successfully in the Kernel.
But when I look at it in the playground, I see that it has been partially created (country and other required fields have been « lost ») :
{ "@id" : "http://data.ozwillo.com/dc/type/orgfr:Organisation_0/FR/testCreaOrga1755", "o:version" : 0, "@type" : [ "orgfr:Organisation_0", "org:Organization_0", "odisp:Displayable_0", "relt:Target_0", "adrpost:Postal_0", "orgpu:PublicOrg_0" ], "dc:created" : 2016-01-07T17:55:57.000+01:00, "dc:modified" : 2016-01-07T17:55:57.792+01:00, "dc:creator" : c06581b1-796a-4459-9ba3-23874c890c6a, "dc:contributor" : c06581b1-796a-4459-9ba3-23874c890c6a, "org:legalName" : [ { "v" : testCreaOrga1755, "l" : fr } ], "org:status" : Normal Activity, "org:sector" : Private, "org:altName" : [ { "v" : , "l" : fr } ], "org:regNumber" : testCreaOrga1755 }Nearly at the same time (yes, there is a 1 minute and some seconds gap between the two servers), I see this in the DC log (but really don't know if it is related) :
The text was updated successfully, but these errors were encountered: