Feature #9432

Default value for the private issue flag

Added by Martin G 7 months ago. Updated 16 days ago.

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

0%

Category:Issues
Target version:Candidate for next major release
Resolution:

Description

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

20120303053333_issues_is_private_by_default.rb (271 Bytes) Magnifier (OPENTIA) Lucas J. González, 2012-03-03 17:35


Related issues

related to Feature #7414: Private issues Closed 2011-01-22

History

#1 Updated by Etienne Massip 7 months ago

  • Category set to Issues

#2 Updated by ruslan sharipov 7 months ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

#3 Updated by Etienne Massip 7 months ago

  • Status changed from Resolved to New
  • % Done changed from 100 to 0

#4 Updated by liku xiong· 7 months ago

  • % Done changed from 0 to 10

#5 Updated by liku xiong· 7 months ago

  • % Done changed from 10 to 100

#6 Updated by Etienne Massip 7 months ago

  • Target version set to Candidate for next major release

#7 Updated by Bruno Medeiros 6 months 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!

#8 Updated by Geert Smit 3 months 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.

#9 Updated by (OPENTIA) Lucas J. González 3 months 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,

#10 Updated by (OPENTIA) Lucas J. González 3 months ago

  • Status changed from New to Resolved

#11 Updated by (OPENTIA) Lucas J. González 3 months 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.

#12 Updated by Etienne Massip 3 months ago

  • Status changed from Resolved to New

#13 Updated by William Roush 24 days ago

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

#14 Updated by Bruno Medeiros 23 days 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?

#15 Updated by Mischa The Evil 23 days 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.

#16 Updated by Bruno Medeiros 16 days 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.

#17 Updated by Mischa The Evil 16 days 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...

Also available in: Atom PDF