Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

permissions update for published nodes #10420

Closed
vbradnitski opened this issue Feb 15, 2024 · 2 comments · Fixed by #10428
Closed

permissions update for published nodes #10420

vbradnitski opened this issue Feb 15, 2024 · 2 comments · Fixed by #10428
Assignees
Labels
Milestone

Comments

@vbradnitski
Copy link
Contributor

We need a way for a smooth permission change of published nodes without of republishing it.
Steps to poc:

  • find all "master" versions of node and it's children.
  • change permissions for it by creating new versions and redirection master branches on it.
  • find the draft versions of the changed contents and redirect it to the new versions (only if master and draft referenced the same version before )

To investigate:

  • diff of the trees in master and draft(diff pathes, extra content and so on)
@vbradnitski vbradnitski self-assigned this Feb 15, 2024
@sigdestad
Copy link
Member

@vbradnitski - I believe the above spec is not reflecting what we really want. Basically, when permissions are changed in one brach, all other branches must instantly reflect the same permissions for the same item. A solution might be to drop the "inherit permissions" flag in the data, and rather just propagate effective permissions on each item.

We can implement the inheritance feeling as a UI feature instead, if a permission line is the same as its parent, show it as grey.

This way, an editor can work in draft mode, change permissions in the tree, and permissions for all affected items are instantly updated across all branches. Should permissions be updated in the master brach, the same permissions will instantly be applied to drafts. A potential solution is simply to store permissions outside of versions, in a new nodeindex maybe?

@rymsha
Copy link
Contributor

rymsha commented Feb 16, 2024

Redo inheritPermissions - is a much bigger task (including migration of blobs).
Besides algorithm described does not take into account that draft tree and master tree might be different.

We should stick to plan where we first try to modify as little code as possible. Description does not cover important detail - modify latest draft versions with new permissions. This is the first step. In the algorithm.

@alansemenov alansemenov linked a pull request Mar 11, 2024 that will close this issue
@rymsha rymsha added the Feature label Mar 14, 2024
@rymsha rymsha added this to the 8.0.0 milestone Mar 14, 2024
rymsha pushed a commit that referenced this issue May 6, 2024
* remove inheritPermissions field #10424

* permissions update for published nodes #10420 (#10428)

* get 'inheritPermissions' flag back for Node and Content #10442

* target branches are upgraded with obsolete version data #10454

* js api changes #10489 (#10493)

* remove permissions from node/content modify flow #10443 (#10492)

* merge with existing permissions #10494 (#10499)

* applyPermissions - subtree selection #10485 (#10515)

* rename mode to scope #10520 (#10521)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants