Non editable profile - even if loggedin

[timea-solid]

I am in a new profile and am trying to addd a first project webID(https://solidos.solidcommunity.net/profile/card#me) and I get a big fat error. I am logged in.
I tried logout and login again. I can edit other parts like resume but not this.

debug.ts:12 Projects mutation save failed Error: Exception in update: Error: Update: Can't make changes in uneditable <https://timea2.pivot-test.solidproject.org:3000/profile/card> Error: Update: Can't make changes in uneditable <https://timea2.pivot-test.solidproject.org:3000/profile/card> undefined Error: Update: Can't make changes in uneditable <https://timea2.pivot-test.solidproject.org:3000/profile/card> undefined at :3000/profile/Update…:15) undefined:0:0 at :3000/mashlib.js:138838:9 undefined:0:0 at new :3000/profile/Promis…us>) undefined:0:0 at :3000/profile/rdfMut…:10) undefined:0:0 at :3000/profile/rdfMut…:11) undefined:0:0 at :3000/profile/projec…:11) undefined:0:0 at :3000/profile/projec…:11) undefined:0:0 at :3000/profile/Object…:15) undefined:0:0 at :3000/profile/Object…:53) undefined:0:0 at async s.<anonymous> (dialog.ts:410:16) at rdfMutationHelpers.ts:256:20 at rdfMutationHelpers.ts:251:15 at new Promise (<anonymous>) at rdfMutationHelpers_esm_C (rdfMutationHelpers.ts:249:10) at rdfMutationHelpers_esm_T (rdfMutationHelpers.ts:379:11) at projects_mutations_esm_m (mutations.ts:175:9) at projects_mutations_esm_h (mutations.ts:186:9) at Object.onSave (ProjectEditDialog.ts:186:13) at Object.beforeClose (dialog.ts:563:27)

[timea-solid]

Update: It seems I had the same issue on editing skills too.

[timea-solid]

This seems to mee a missing check of editable or maybe it looses being editable or something...

[timea-solid]

Maybe also related: I am in preferences and I have an editable error too:

Maybe there is a session problem... maybe we loose being logged in info?! Further testing is necessary.

[timea-solid]

I also saw this on a friend's page.. I was logged in but the drag and drop did not appear. It is like it lost the info that I am still logged in.

[SharonStrats]

After lots of investigation I realized this problem is specific to the restore Session not a fresh login. What's happening is that when the resources are first fetched, they are fetched anonymously and when the "restored login" comes through it does not refresh the resources so they are authenticated. This affects whether we can PATCH the resource versus PUT a completely new one. RDFLIB checks whether a resource is edittable before it does a PATCH, but for PUT it doesn't. The failure we are seeing is the edittable check like you mentioned. The user is logged in so of course when it does the PUT it works without a problem.

This problem was further complicated by the fact that you can't just refresh an already fetched resource because it has a check for that and the data that existed made it fail this check. Because of this we had to remove the resource/resources so it/they can be refreshed with authentication. As well the session restore event was not being emitted due to a timeout.

Note: The legacy EditProfileView checks this status before it will display the editor at all, so the user would get the message and have to relogin in order to see/use the editor.

Previous History
I am pretty sure we ran into this problem previously, definitely we had some inconsistencies in what was happening. I remember them and the mutation code kept evolving because of it. This is one reason it's only a problem with projects, skills, heading and bio. Resume, contact info, social and languages are okay.

The other sections already leaned to PUT instead of PATCH for some different reasons. One is that I added the prefixes, so if a profile document does not have prefixes it will add them when it writes/changes data and that requires a PUT. Also, I think because of inconsistencies I ended up having to add in logic for checks to forcePut and also a fallback to PUT if PATCH didn't work. I'm still slightly confused as to why the fallback wasn't working for these 2 sections, it basically wasn't an exact match for the error check that then decides to use PUT.

We already have a ticket for reviewing/redoing the mutations. I think this would be another reason to, because I think we really should be using PATCH not falling back to a PUT. I think we should only PUT if we want to add the prefixes. But this is just an opinion/gut feel. I would like to discuss it further in a meeting to see what is the best protocol for this. The legacy edit profile only uses PATCH.

I am not sure about the friend's page yet. I will have a look at that soon.

Two fixes:
SolidOS/solid-logic#325
SolidOS/profile-pane#449