We merged !350 (merged), but there are several improvements we could make. In particular:

• @anoe reported here that he's observing some GQL errors when publishing a corpus. I have seen those myself occasionally but not in the context of my MR, but is worth investigating and trying to reproduce;

• At the moment when we publish a corpus, we end up with what seems to be "Two copies" -- we see the node still in the private subtree and in the public tree, which might be confusing. @anoe , perhaps we should somehow hide any published node from its source (i.e. private) subtree?

• At the moment, the backend supports two "publishing modes": one is static and doesn't allow even the original owner to modify a published node, and the other is more dynamic. However, using the /move API we can only publish using the "static" mode, whereas it would be nice to have an API endpoint to be able to specify such NodePublishPolicy in the body of a POST request, as a JSON payload. I propose we add a /publish endpoint to do just that, so that the frontend can decide which endpoint to call in one case or the other.

• At the moment the backend doesn't expose any information about the original NodePublishPolicy in the NodeTree we return when we call /tree and /first_level. This means that the frontend doesn't have a way to show nodes in a different way according if they are "static" or "dynamic", so we should fix that.

• The story around Notes is unclear, because by default notes will be editable by anybody, so ideally if we publish a corpus containing a Notes children, we should somehow generate under the hood an HTML blob and have it nested under the published node, seamlessly.