Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Submit feedback
    • Contribute to GitLab
  • Sign in
haskell-gargantext
haskell-gargantext
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 161
    • Issues 161
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 8
    • Merge Requests 8
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • gargantext
  • haskell-gargantexthaskell-gargantext
  • Merge Requests
  • !350

Merged
Opened Oct 07, 2024 by Alfredo Di Napoli@AlfredoDiNapoli
  • Report abuse
Report abuse

Foundational work for publishing a (Corpus) Node

Fixes #400. This is a beefy MR which deserves some explanation on how it works.

Demo GIF first

publishing_corpus

How it works

Me and Alexandre discussed a bit on which design to go for, and decided to pick the easiest design we could think of. Therefore, there a bunch of points worth discussing:

  • In order to publish a node, users must explicitly move it into their Public folder. This generates under the hood a soft link (to use a filesystem terminology), so that the node is visible in their Public directory as well as any other Public folders for any logged-in user;
  • Only the owner of the node can publish it (i.e. the logged-in user which user_id matches the one stored in the DB node);
  • A published node (in the current implementation) can still be modified (by the original owner) after publication;
  • Only the publisher can modify (i.e. edit/delete/move etc) a published node.
  • Every single children under a published node will be published as well, so one has to be careful about what gets shared.
Edited Nov 11, 2024 by Alfredo Di Napoli

Check out, review, and merge locally

Step 1. Fetch and check out the branch for this merge request

git fetch origin
git checkout -b adinapoli/issue-400 origin/adinapoli/issue-400

Step 2. Review the changes locally

Step 3. Merge the branch and fix any conflicts that come up

git fetch origin
git checkout origin/dev
git merge --no-ff adinapoli/issue-400

Step 4. Push the result of the merge to GitLab

git push origin dev

Note that pushing to GitLab requires write access to this repository.

Tip: You can also checkout merge requests locally by following these guidelines.

  • Discussion 14
  • Commits 16
  • Pipelines 21
  • Changes 45
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
1
Labels
Ready to merge
Assign labels
  • View project labels
Reference: gargantext/haskell-gargantext!350

Revert this commit

This will create a new commit in order to revert the existing changes.

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.

Cherry-pick this commit

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.