Redmine

The following code is a sample implementation.

diff --git a/app/views/projects/_members_box.html.erb b/app/views/projects/_members_box.html.erb
index e915ab910..72d7fb97b 100644
--- a/app/views/projects/_members_box.html.erb
+++ b/app/views/projects/_members_box.html.erb
@@ -4,5 +4,10 @@
     <% @principals_by_role.keys.sort.each do |role| %>
       <p><span class="label"><%= role %>:</span> <%= @principals_by_role[role].sort.collect{|p| link_to_user p}.join(", ").html_safe %></p>
     <% end %>
+    <% if @project.is_public %>
+      <hr>
+      <p span class="label"><%= l(:field_is_public) %>:</span> <%= l(:general_text_Yes) %>
+      <em class="info"><%= Setting.login_required? ? l(:text_project_is_public_non_member) : l(:text_project_is_public_anonymous) %></em>
+    <% end -%>
   </div>
   <% end %>
</diff>

+1

Private information may be leaked if the settings are mistakenly made public when creating a project.
I think this feature is needed to quickly notice that the project is open to the public.

+1

On a somewhat related note:
About 1 month ago we also implemented and posted a patch for a new permission for publishing projects in response to #9029 . Maybe this could be considered for Redmine 5.0 ? It would surely help to counter the security concerns regarding public projects....

Maybe we should add a Public badge next to Overview title as we have for issues and versions.

Mizuki ISHIKAWA wrote:

I have attached a patch that adds a test to #35044#note-1. => 0001-Add-test.patch

I also made 0002-Add-project-public-badge.patch to add a badge based on the opinion of #35044#note-5. Please let me know if you need to separate the issue.

Thank you for the patch but I think it is better to post as a new issue because the feature implemented by the patch is very different from the original proposal.

In addition, I suggest the following improvements:

• The badge is for a single project, the noun should be singular ("projects" -> "project")
• Maybe "public project" is too long. I think "public" is enough
• The color #d22 is too prominent. Also, the red color gives a wrong impression that the public project itself is dangerous and bad. Making a project public is not dangerous. The danger is that you will set it up incorrectly

Go MAEDA wrote:

Thank you for the patch but I think it is better to post as a new issue because the feature implemented by the patch is very different from the original proposal.

In addition, I suggest the following improvements:

• The badge is for a single project, the noun should be singular ("projects" -> "project")
• Maybe "public project" is too long. I think "public" is enough
• The color #d22 is too prominent. Also, the red color gives a wrong impression that the public project itself is dangerous and bad. Making a project public is not dangerous. The danger is that you will set it up incorrectly

Thank you for your feedback.
I made a new issue #35221 and attached a new patch that was modified based on the feedback.

We should show this info only once on this page and the members box is not the best option because the project visibility is an attribute of the project, not of the members. Also, in projects with multiple members or news, the information will be visibile only after more or less scroll.

From my point of view, having the bagde with a title attribute should be enough. If you don’t like this approach, then we should show this info in the project attributes box (top left).

One more thing, project content visibility depends on the rights configured for anonymous/non member roles, maybe the message should be more specific because the current one says that the content is publicly available. Also, in an era of SaaS/cloud applications, we should avoid using the word network. .

What I wanted to show in the members box is public not whether the project is public or not, but anonymous users and nonmembers can access the project.

I think it would be good to discuss how to indicate that a project is public, based on the patch in #35221.

Go MAEDA wrote:

What I wanted to show in the members box is public not whether the project is public or not, but anonymous users and nonmembers can access the project.

I understand now and I think it's a valuable information.

I think it would be good to discuss how to indicate that a project is public, based on the patch in #35221.

Ok, I will add my proposals there in the following days.