IBX-10854: Added ability to hide content item drafts

[vidarl]

🎫 Issue	IBX-10854

It is not possible to publish content in hidden state

For QA:

Note

Edited by @alongosz

Requires security testing, e.g., if user who doesn't have hide/reveal permissions is now able to do it.

Documentation:

[alongosz]

AFAIR this is by-design. There's no purpose to hiding content drafts because content drafts can be read by people with versionread policy, the same as hidden content can be accessed. Are you trying to fix some fatal error or enable hiding drafts? TL;DR;.

[vidarl]

There's no purpose to hiding content drafts because

yes, it is. If you don't want content to be visible at time of publishing.

Are you trying to fix some fatal error or enable hiding drafts?

@alongosz
I am trying to publish content as hidden. The use-case is:
Write a new article but translate it to multiple languages before making it visible. Since admin-ui cannot edit multiple languages for the same version, publish it as hidden would do the trick

edited....

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[vidarl]

ping @alongosz @Steveb-p : I have answered on your comments. Please have a look again

[Steveb-p]

Doesn't this mean, with this change, that for drafts every user has ability to hide & reveal?

Because we won't be checking permission resolver for drafts.

[vidarl]

You are right. Fixed in ca2b306.
Unsure if it 100% safe to have $targets=[] in parameter to canUser() though, but seems to work fine for me when I test with limitation on content/hide policy

@Steveb-p

[vidarl]

Explanation of what happens when $targets=[] is addressed in #667 (comment)

@Steveb-p

[konradoboza]

@vidarl please make sure #667 (comment) is addressed, PR is rebased and the CI lits green.

[vidarl]

@vidarl please make sure #667 (comment) is addressed, PR is rebased and the CI lits green.

@konradoboza
Done. Only sonar complains now about duplicated code in Tests. Which should be considered as a false-positive

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[vidarl]

@alongosz, @konradoboza, @Steveb-p : Can you have a new look on this one. I think all review comments has been addressed

[alongosz]

Another round of review:

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tomaszszopinski]

Note from QA:
Hidden content item is created by the API, but there are some differences:

• 'eye' icon is missing
• hidden content item is not greyed out

[tomaszszopinski]

Adding request changes, so it more visible (see my earlier comment).

[vidarl]

Adding request changes, so it more visible (see my earlier comment).

@tomaszszopinski
Yes, I was aware of it, but had some issues with the new tests that was needed.
Your finding was correct, it was real bug you found. What happen was that the location was not marked as invisible if the draft was published as hidden.
Fixed this in d969b17
However, CI on core has some other problems now ( @alongosz is already working on it). Once that is fixed, I expect my new tests and the fix to work as well

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tomaszszopinski]

QA approved on Ibexa DXP 4.6 exp.

[mnocon]

Hi! Adding the Doc needed label, because the use case mentioned by Vidar is interesting and the best practices for handling this should to be documented:

The use-case is: Write a new article but translate it to multiple languages before making it visible. Since admin-ui cannot edit multiple languages for the same version, publish it as hidden would do the trick

Thinking about this right now, I'm not sure if I'd recommend hiding the draft to for all cases, I think it's:

Case 1: Article content doesn't have to remain a secret:

1. Hide the draft
2. Publish it
3. Translate into multiple languages
4. Reveal (unhide) it

Because hidden content is accessible through the REST API, this flow doesn't work for cases where the Article content has to remain a secret (for example, company merger announcement or anything that could move the stock market).

For content that has to remain a secret before being published in multiple languages, the flow would be:

Case 2: Article content has to remain a secret

1. Create a section meant with rectricted read access (internal only)
2. Create and publish an article there
3. Translate it
4. Move it to the intended (generally available) location

This way the content remains a secret until it can be oficially announced, and cannot be previewed by REST API before that.

The second case does not rely on "unsafe" hide/reveal, hide/reveal can be used as a simplified flow for not business critical content.

Does it make sense to you as a recommendation?