Project

General

Profile

Actions

Feature #9432

open

Default value for the private issue flag

Added by Martin G over 12 years ago. Updated 11 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Issues
Start date:
2011-10-17
Due date:
% Done:

0%

Estimated time:
Resolution:

Description

It would be useful to have the possibility, to set the default value for the "private issues"-flag for each project.


Files


Related issues

Related to Redmine - Feature #7414: Private issuesClosed2011-01-22

Actions
Related to Redmine - Feature #17132: add ability set "private note" visibility for specific roleNew

Actions
Related to Redmine - Feature #12089: Hide Issue HistoryNewJean-Philippe Lang

Actions
Related to Redmine - Defect #13522: Private field is shown as requiredNewJean-Philippe Lang

Actions
Has duplicate Redmine - Feature #14390: Notes private by defaultClosed

Actions
Has duplicate Redmine - Feature #20102: Possibility to set new issues in private by default Closed

Actions
Has duplicate Redmine - Feature #24636: All issues private - Setting by projectClosed

Actions
Actions #1

Updated by Etienne Massip over 12 years ago

  • Category set to Issues
Actions #2

Updated by ruslan sharipov over 12 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100
Actions #3

Updated by Etienne Massip over 12 years ago

  • Status changed from Resolved to New
  • % Done changed from 100 to 0
Actions #4

Updated by liku xiong· over 12 years ago

  • % Done changed from 0 to 10
Actions #5

Updated by liku xiong· over 12 years ago

  • % Done changed from 10 to 100
Actions #6

Updated by Etienne Massip over 12 years ago

  • Target version set to Candidate for next major release
Actions #7

Updated by Bruno Medeiros over 12 years ago

  • % Done changed from 100 to 0

I tried one more time to create a patch for this, but failed :(

There is a mechanism to set safe_attributes, and I could understand it because I'm ruby/rails noob. If someone have a clue, please post it!

Actions #8

Updated by Geert Smit about 12 years ago

This feature would be really helpful. There are almost always 2 streams of issues, internal and for the customer. It happens a lot that developers forget to choose private for internal issues. So we choose to keep a 2 project strategy for now.

Actions #9

Updated by (OPENTIA) Lucas J. González about 12 years ago

Geert Smit wrote:

It happens a lot that developers forget to choose private for internal issues.

It's just a matter of upgrading the issues model.

We have uploaded an Active Record file for this migrate. We tested it and are using it. Now, all issues are created private by default.

Greetings,

Actions #10

Updated by (OPENTIA) Lucas J. González about 12 years ago

  • Status changed from New to Resolved
Actions #11

Updated by (OPENTIA) Lucas J. González about 12 years ago

I wrongly marked this as Resolved (can't revert the change now). The issue is not resolved as it is not configurable at project level.

Actions #12

Updated by Etienne Massip about 12 years ago

  • Status changed from Resolved to New
Actions #13

Updated by William Roush almost 12 years ago

+1 on this, really useful if you're running a hybrid environment (behind closed doors development + open tickets among users).

Actions #14

Updated by Bruno Medeiros almost 12 years ago

Lucas, I don't understand how your patch works.. How could a DB migration script make the private checkbox appear checked/unchecked when you're creating a new issue? Shouldn't you change the Issue model? Sorry if it's a stupid question, I'm a ruby noob, but I can't really understand it.

PS.: I see the redmine logs when inserting a new issue, and the value "false" is sent to the database. Am I crazy?

Actions #15

Updated by Mischa The Evil almost 12 years ago

Bruno Medeiros wrote:

Lucas, I don't understand how your patch works.. How could a DB migration script make the private checkbox appear checked/unchecked when you're creating a new issue? [...]

The patch sets a default value for the :is_private attribute of the :issues column.

Actions #16

Updated by Bruno Medeiros almost 12 years ago

Mischa The Evil wrote:

The patch sets a default value for the :is_private attribute of the :issues column.

Ok, I got it, but it doesn't seem to change the default behavior. The 'false' comes from the application, it's not false because of the database default value, AFAIK.

Actions #17

Updated by Mischa The Evil almost 12 years ago

Bruno Medeiros wrote:

Mischa The Evil wrote:

The patch sets a default value for the :is_private attribute of the :issues column.

Ok, I got it, but it doesn't seem to change the default behavior. The 'false' comes from the application, it's not false because of the database default value, AFAIK.

Bruno, I'm currently not in the position to test this patch, but since it's a DB-migration script you should run RAILS_ENV=production rake db:migrate after creating the "patch"-file under /db/migrate. That should do the trick...

Actions #18

Updated by Bruno Medeiros almost 12 years ago

Mischa The Evil wrote:

Bruno, I'm currently not in the position to test this patch, but since it's a DB-migration script you should run RAILS_ENV=production rake db:migrate after creating the "patch"-file under /db/migrate. That should do the trick...

Sorry for the misunderstanding, I couldn't believe that a script, which is supposed to alter the database, could also change the default value on the view form, before the entry reach the database. Rails is really impressive on this!

I can confirm that the script works great, thanks all!

Actions #19

Updated by Anonymous over 11 years ago

Bruno Medeiros wrote:

I can confirm that the script works great, thanks all!

Bruno (or anyone else), can you comment on whether this enables private=true for users who don't have permission to use it?

For example, if the customer role does not have permission to set an issue private, preventing the checkbox from appearing on forms they see, and private=true is the default for new issues, will any new issues filed by a customer also default to private=true?

My goal is for all internal roles (developers, managers, etc.) to see the checkbox, checked by default, while customers do not see the checkbox, and all issues they file are public.

Actions #20

Updated by Anonymous over 11 years ago

So I ran this locally to see if I could answer my own question. I'm a little saddened by the results: All new issues have the Private option checked by default.

All, including new issues from users without the right to set issues private. Even though the check box isn't visible, it's still defaulting to a value of true. While this isn't devastating, it's a little less handy than I originally had hoped. Our developers can file issues without worrying about forgetting to keep them private, but externally filed issues will need to be reviewed and made public.

Actions #21

Updated by Anonymous over 11 years ago

Hey folks, this isn't much, but I went ahead and took the patch approach to solve this one for my needs...

In app/controllers/issues_controller.rb I added the following line toward the end of the def build_new_issue_from_params block (around line 410 in the case of v2.1.2):

@issue.is_private = true if User.current.allowed_to?(:set_own_issues_private, @project)

This is meant to work without using the db migrate script. Here's my setup for this:

  1. Split your roles in two sets, some external (customer), some internal.
  2. Allow internal roles to view all issues, public and private, and restrict external roles to non-private issues.
  3. Allow internal roles to set their own issues private, but do not give this right to externals.

In place, this makes all new issues filed by internal users private, while all new issues filed by customers must be public. It's not perfect, though: for internal roles, new issues will always be created private, even if you uncheck the box on the form, requiring the filer to then update the issue to make it public.

Since unchecking the box does work when using the db migrate script, it might be possible to do a hybrid of the two...using the script the set the default value to private, and then changing the patch to set the value to false if the permission does NOT exist. If there's a way to do that, it would allow internal users to uncheck private when desired, and external users don't need that flexibility since the option won't exist for them anyway...

But I have no doubt there are simpler solutions. I'm just a total noob.

Actions #22

Updated by Anonymous over 11 years ago

Yeah, so, simpler solution:

app\views\issues\_form.html.erb

In the very first block (for the is_private safe attribute), right around line 6, change:

<%= f.check_box :is_private, :no_label => true %>

to:

<%= f.check_box :is_private, :checked => @issue.new_record? || @issue.is_private, :no_label => true %>

Super simple, right? XD It's already wrapped in a check for permission to set the attribute.

No other modifications necessary. Sigh, lol. I've learned way too much about Redmine during this effort!

This patch exactly meets my needs, no caveats so far. This guarantees that external users without set-private rights will always post public issues, and internal users will always default to private, with the freedom to uncheck the box.

Actions #23

Updated by Bruno Medeiros over 11 years ago

Joshua DeClercq, I'm happy you could manage your problem, but what I wanted for my needs was really the first patch. I want to have all issues private, even if the user don't have rights to change. What is confusing here is that there is no permission to "make issue private", there is a permission to "change private/public flag". So, if the user doesn't have this permission, the issue is public by default. I wanted to change that: If the user doesn't have this permission, the issue is private.

Actions #24

Updated by Anonymous over 11 years ago

Bruno, understood. For my case, and a few others I was pressured into figuring this out for, the idea was for customers to have shared visibility, while internal issues were internal unless management decides to make them visible to customers.

If issues are always private, even for those who don't have the permission, there's no shared visibility between this class of users, since the only private issues that would be visible to them would be the ones they're involved in.

If, however, there were an option to extend 'involvement' to members of your group, if you're a member of the project via that group, that would be pretty cool and achieve the same result.

Ultimately, though, I prefer a solution that doesn't involve a DB migration. A code tweak just requires a server restart, and makes me a lot less nervous.

Actions #25

Updated by Zube Zahn over 11 years ago

additionally: It would be even nicer, if one could set a default value for the "private" flag depending of the tracker used.

e.g. I am using an "Administrative Tasks" Tracker that handles tasks beside the regular software development process in our Redmine. However, I would prefer having those tasks within this Tracker private by default.

Actions #26

Updated by Anonymous over 11 years ago

What you're describing might be better suited to a plug-in. It would need to add an extra field to each tracker's settings, and then that field would need to be checked against with whatever routine runs to refresh the form when you change the tracker, as well as making the usual permission checks.

It's a compelling idea, but it feels like it's only half of a good user experience. Once you can set trackers to private/public by default, users will want the option to hide private-by-default trackers from members who don't have privacy permissions, so they can't create any of those issues in the first place. And THAT is much more complicated.

Actions #27

Updated by François Bélingard about 11 years ago

+1. It would be a very useful feature for absent minded people like me.

Actions #28

Updated by Jai prakash about 11 years ago

+1 for this

Joshua Khoele I have tested out your code and it is great . I am looking to do the same thing for Private Notes too .
I have no experiance with Ruby on Rails . Can u please help me.

My use case is almost same as yours . Private notes should be checked by default for users having "Set notes as private" privilage.

Actions #29

Updated by Anonymous about 11 years ago

Jayaprakash S -- I don't have a 2.x server to play with right now, so I can't say for sure if this works. You'll want to look at /app/views/issues/_edit.html.erb though, right around line 34, which in stock 2.2 reads:

<label for="issue_private_notes"><%= f.check_box :private_notes, :no_label => true %> <%= l(:field_private_notes) %></label>

You should be able to do something very similar to what I did before, adding to the check_box definition so it ends up something like:

<label for="issue_private_notes"><%= f.check_box :private_notes, :checked => true, :no_label => true %> <%= l(:field_private_notes) %></label>

Since this line is preceded by a permission check, it should only affect users allowed to post private comments. Since the check box doesn't appear when editing an existing comment later, there's no need for some kind of 'new comment' check, either (like with the private issue earlier), and a simple ':checked => true' should suffice.

Let me know if this works for you!

Actions #30

Updated by Anonymous about 11 years ago

The original issue describes wanting to use these settings on a per-project basis. Here's one way to do it, step by step...

1. Start with a db migration: You need a place to store the privacy settings. You'll want to create a new /db/migrate/*.rb file, let's say 20130226022500_add_default_privacy_checkboxes.rb. You can have either or both private issues/comments checked by default:

class AddDefaultPrivacyCheckboxes < ActiveRecord::Migration
  def self.up
    add_column :projects, :private_issues_is_checked, :boolean, :default => false, :null => false
    add_column :projects, :private_notes_is_checked, :boolean, :default => false, :null => false
  end

  def self.down
    remove_column :projects, :private_issues_is_checked
    remove_column :projects, :private_notes_is_checked
  end
end

It's pretty readable, so you can figure out which lines to remove if you don't want both values. After this, from your console run: rake db:migrate RAILS_ENV=production

Now you get to edit a few files.

2. /app/views/issues/_form.html.erb From comment 22 above, this is where you get the private issue box checked by default. We're adding an extra check to it:

<%= f.check_box :is_private, :checked => (@issue.new_record? && @project.private_issues_is_checked?) || @issue.is_private, :no_label => true %>

3. /app/views/issues/_edit.html.erb From comment 29 right above this, where I explain how to check private comment by default. Instead of :checked => true, you want the following:

:checked => @project.private_notes_is_checked?

4. /app/views/projects/_form.html.erb Now to add check boxes to the project Settings page. Around line 17 you'll see the code to create a checkbox for :is_public. Insert a new line (or two) after it, for the new setting(s):

<p><%= f.check_box :private_issues_is_checked %></p>
<p><%= f.check_box :private_notes_is_checked %></p>

5. /config/locales/en.yml Those checkboxes need labels, so add them. Around line 300, you'll find a block of all the field_* messages. You need to add two new messages for field_private_issues_is_checked and/or field_private_notes_is_checked. For example:

  field_private_issues_is_checked: Private issues by default
  field_private_notes_is_checked: Private notes by default

6. /app/models/project.rb Add the new fields to the safe_attributes list, otherwise Redmine won't save changes to the check boxes on the project Settings page. These are around line 632. Append or insert the field names, making sure to add comma separators where necessary. My final looked like:

  safe_attributes 'name',
    'description',
    'homepage',
    'is_public',
    'private_issues_is_checked',
    'private_notes_is_checked',
    'identifier',
    'custom_field_values',
    'custom_fields',
    'tracker_ids',
    'issue_custom_field_ids'

Restart Redmine, and that does it. You now have a project-by-project setting for whether issues and/or comments are checked 'Private' by default for all users with permission to set it private. Users without permission to do so will still only post publicly.

Actions #31

Updated by Jai prakash about 11 years ago

Thanks Joshua

It worked perfectly well . Just the kind of feature i was looking for.

Actions #32

Updated by Jai prakash about 11 years ago

Hello Joshua,

Is it possible to put these changes in a plugin ? In case if I want to upgrade my redmine,plugin will be better to port these changes to new redmine instance right?
I am thinking about makig a plugin , but dont know if its even possible.

Actions #33

Updated by Anonymous about 11 years ago

Maybe. I have zero experience building plugins. I prefer to tinker and play in the code directly. If I ever figure plugins out, I'll probably use something simple like this as a practice run.

From what I've seen, plugins can become very buggy after a Redmine upgrade, potentially breaking itself or large chunks of Redmine. I've come to like having a list of manual tweaks to apply after an upgrade instead, because I can adapt to new code as I go. I realize this is NOT an option for everyone, though, so I'll see what I can do.

Actions #34

Updated by Toshi MARUYAMA over 10 years ago

Actions #35

Updated by JayD - over 10 years ago

Joshua DeClercq wrote:

The original issue describes wanting to use these settings on a per-project basis. Here's one way to do it, step by step...

Why wouldn't you create a patch together with a pull-request on github for such a useful feature?

-> https://github.com/redmine/redmine

Actions #36

Updated by Toshi MARUYAMA almost 10 years ago

  • Related to Feature #17132: add ability set "private note" visibility for specific role added
Actions #37

Updated by Nate Swinburne over 9 years ago

Here's a way to set new issues private by default on a tracker-specific basis (as opposed to for an entire project). I've made a few small changes to Joshua's instructions in comment #30 above to accomplish this.

1. Start with a db migration. Create a new /db/migrate/*.rb file, e.g., 20140801_add_default_privacy_checkbox.rb.

class AddDefaultPrivateCheckbox < ActiveRecord::Migration
  def self.up
    add_column :trackers, :private_issues_is_checked, :boolean, :default => false, :null => false
  end

  def self.down
    remove_column :trackers, :private_issues_is_checked
  end
end

After this, from the command line run: rake db:migrate RAILS_ENV=production

2. /app/views/issues/_form.html.erb Change the :is_private code to this:

<%= f.check_box :is_private, :checked => (@issue.new_record? && issue.tracker.private_issues_is_checked?) || (!@issue.new_record? && @issue.is_private?), :no_label  => true %>

3. /app/views/trackers/_form.html.erb Add the checkbox to the tracker form. Insert after the :is_in_roadmap line.

<p><%= f.check_box :private_issues_is_checked %></p>

4. /config/locales/en.yml Add the following line to the section with all the field_* messages (e.g., line 324)

field_private_issues_is_checked: Private issues by default

5. /app/models/project.rb Add the new field to the safe_attributes list (around line 632). It should look something like:

safe_attributes 'name',
    'description',
    'homepage',
    'is_public',
    'private_issues_is_checked',
    'identifier',
    'custom_field_values',
    'custom_fields',
    'tracker_ids',
    'issue_custom_field_ids'

6. Reboot Redmine for the changes to take effect.

Actions #38

Updated by Barry Fisher over 9 years ago

Thanks to Nate and Joshua for sharing your solutions.

A couple of notes further to Nate's post... I've rolled up his described steps into a single patch that worked for me. I had to change 20140801_add_default_*privacy*_checkbox.rb to 20140801_add_default_*private*_checkbox.rb. I'm not entirely sure why the migration failed because of the difference is name- perhaps it has a magic meaning in Rails (noob question?!)

I also was running the Redmine Tracker Control Plugin (http://www.redmine.org/plugins/redmine_track_control), and as this plugin overrides the form partial a further amendment was required- which I've added in another patch named: add_default_private_checkbox__with_redmine_track_control_plugin.patch

I'll be interested to hear how people get on applying the patch. Of course, don't forget to run rake db:migrate RAILS_ENV=production
...and reboot redmine. I just restart apache (with Passenger), which make this good to go!

Note: to apply the patch, download the patch to your base redmine directory and run:

patch -p1 < add_default_private_checkbox__core.patch

Or:

patch -p1 < add_default_private_checkbox__with_redmine_track_control_plugin.patch

Cheers!

Actions #39

Updated by Jean-Philippe Lang almost 9 years ago

  • Has duplicate Feature #20102: Possibility to set new issues in private by default added
Actions #40

Updated by Go MAEDA over 7 years ago

  • Has duplicate Feature #24636: All issues private - Setting by project added
Actions #41

Updated by Go MAEDA about 7 years ago

Actions #42

Updated by Luis Roa about 7 years ago

Hi, I wrote a plugin for this feature:

https://github.com/luisr9/redmine_private_issues

Steps
1. Install plugin.
2. go to setting of plugin and check "enabled".

After enabled the plugin, all new issue will be private.

I tested the plugin with redmine 3.1 and 3.2. I don't know if it works and other versions.

Note: If a user will update a non private issue, the plugin will change to private the issue.

Actions #43

Updated by Philip Heise over 6 years ago

Hi,

I updated the patch from comment 38 as it contained one error.

regards

Actions #44

Updated by Anudeep Junuthula about 6 years ago

Hi Philip,

What version of Redmine are you running? None of the patches seem to work on 3.3.3.stable

Thanks

Actions #45

Updated by damien cuvillier almost 3 years ago

Luis Roa wrote:

Hi, I wrote a plugin for this feature:

https://github.com/luisr9/redmine_private_issues
....

Just tested it.
On my point of view, it's too global

Improvement ideas :

  • It would be great that default choice would be private, but if I uncheck checkbox, it goes public
  • Edition not working : that means that I'm unable to make public any ticket
  • It would be great that enabling would be each project scoped

Besides, a great behavior would be checkbox linked to real result.
Currently, even if it's unchecked, issue are posted as private

Actions #46

Updated by Mischa The Evil over 2 years ago

  • Related to Defect #13522: Private field is shown as required added
Actions #47

Updated by Go MAEDA 12 months ago

I wrote a patch that allows you to set a default value for the private field per tracker basis.

The patch adds a "Private by default" checkbox to trackers. On the New issue page, the "Private" checkbox is checked by default when you select a tracker that "Private by default" is set. Of course, you can manually uncheck the "Private" checkbox even for such trackers.

Actions #48

Updated by Go MAEDA 12 months ago

  • Target version changed from Candidate for next major release to 5.1.0

Setting the target version to 5.1.0.

Actions #49

Updated by Go MAEDA 11 months ago

  • Target version changed from 5.1.0 to Candidate for next major release

Go MAEDA wrote in #note-47:

I wrote a patch that allows you to set a default value for the private field per tracker basis.

The patch has a bug that members without both "Set project public or private" and "Set own issues public or private" permissions can create private issues.

Actions

Also available in: Atom PDF