Feature #12005

Mightful workflow field enhancement: hide

Added by # And almost 2 years ago. Updated 8 days ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

90%

Category:Issues workflow
Target version:-
Resolution:

Description

Ability to hide field

Related to #8050

workflow_hidden_field.diff Magnifier (4.79 KB) # And, 2012-10-02 12:03

workflow_hidden_field_v0.03.diff Magnifier (8.73 KB) # And, 2012-10-02 12:03

workflow_hidden_field_DR_v0.04.patch Magnifier (16.5 KB) David Robinson, 2012-10-30 17:31

workflow_hidden_field_DR_v0.05.patch Magnifier (35 KB) David Robinson, 2012-11-05 15:51

workflow_hidden_field_DR_v0.06.patch Magnifier (35.6 KB) David Robinson, 2012-11-07 14:25

workflow_hidden_field_DR_v0.07.patch Magnifier (35.6 KB) Jamie MacIsaac, 2013-01-09 17:08

translation_de.diff Magnifier - German translation for patch (413 Bytes) Daniel Felix, 2013-01-12 14:21

workflow_hidden_field_DR_v0.08.patch Magnifier (31.3 KB) David Robinson, 2013-02-06 13:45

workflow_hidden_field_DR_v0.09.patch Magnifier (32 KB) David Robinson, 2013-02-07 14:08

workflow_hidden_field_DR_v0.010.patch Magnifier (35.4 KB) David Robinson, 2013-02-12 14:00

workflow_hidden_field_DR_v0.011.patch Magnifier (35.4 KB) David Robinson, 2013-02-12 16:00

workflow_hidden_fields_redmine2.4_v1.0.patch Magnifier (15.6 KB) Gurvan Le Dromaguet, 2014-03-06 15:37

workflow_hidden_fields_redmine2.4.4_v1.01.patch Magnifier - Patch file for Redmine v2.4.4 (r12953) (21.8 KB) David Robinson, 2014-03-14 17:22


Related issues

Related to Feature #8050: Mightful workflow field enhancement: visible, read only ... Closed 2011-04-03
Related to Feature #5011: Limit Visible Issue Fields Based on Permissions Closed 2010-03-08
Related to Feature #4707: private fields New 2010-02-01
Related to Feature #9736: custom field visibility based on tracker Resolved
Related to Feature #5037: Role-based issue custom field visibility Closed 2010-03-10
Related to Feature #8313: Restrict Assignee List by Role New 2011-05-06
Related to Feature #9421: Prevent attribute changes once an issue is assigned to a ... Closed 2011-10-13
Related to Feature #8162: Issue custom field visibility per workflow Closed 2011-04-15
Related to Feature #2618: Move some change properties fields into the "more" link New 2009-01-29
Related to Feature #10140: Allow certain fields in an issue to be designated as unco... Closed
Related to Feature #10162: require notes on specific fields getting set to specific ... New
Related to Defect #12954: Required field can't be read-only New
Related to Feature #2979: New issue : choose displayed fields by profile Closed 2009-03-16
Related to Feature #2539: New project setting: mandatory/optional configuration for... New 2009-01-19
Related to Feature #4670: Fine tune "New Issue" New 2010-01-27
Related to Feature #11853: Field permissions New
Related to Feature #4485: Create an ACL privilege for assigning tickets New 2009-12-25
Related to Feature #15782: Workflow Field Permissions - Status-Based Field Visibility New
Related to Feature #15918: Managing "description" field New 2009-12-11
Duplicated by Feature #12249: Configurable required fields per tracker/role with 'Not v... Closed
Duplicated by Feature #11329: Private custom fields Closed
Duplicated by Defect #8302: Wrong columns displayed on Issue list Closed 2011-05-05
Duplicated by Feature #13729: Field permission invisible Closed
Duplicated by Feature #12745: Disable the default "Description/Status/Priority" field Closed
Duplicated by Feature #11963: Hide the estimated times on issues for certain roles Closed
Duplicated by Feature #14162: Hidden Fields - Role Based Closed

History

#1 Updated by Janes Roberto Costa almost 2 years ago

  • % Done changed from 0 to 90

#2 Updated by # And almost 2 years ago

Tested it on trunk today, works fine!

#3 Updated by # And almost 2 years ago

Yes, all copyrights goes to Gurvan Le Dromaguet. Thanks, man.

#4 Updated by Peter Kalvin almost 2 years ago

I would appreciate it so much guys if you could implement this in the next release. Thank you in advance :)

#5 Updated by Tobias Fischer almost 2 years ago

+1

#6 Updated by David Robinson almost 2 years ago

+1

Which one of the attached files is the newest?

#7 Updated by # And almost 2 years ago

David Robinson, latest.

#8 Updated by Daniel Felix almost 2 years ago

It would be quite useful to have this feature in the next release!
+1

#9 Updated by David Robinson almost 2 years ago

The way I understand this, hidden should also be read-only (hidden should not be MORE permissive than read-only, but LESS permissive) in the attached (v0.03) a user that has "hidden access" to a field can still edit it...

I would suggest functionality along the lines of:

  def read_only_attribute_names(user=nil)
    workflow_rule_by_attribute(user).reject {|attr, rule| rule != 'readonly' and rule != 'hidden'}.keys
  end

P.S.: I don't know Ruby, nor anything about the Redmine codebase, so if this suggestion is foolish this is why.

#10 Updated by David Robinson almost 2 years ago

  1. And wrote:

David Robinson, latest.

Thank you # And for your prompt reply.
But I am affraid I see the following:

workflow_hidden_field.diff Magnifier (4.79 KB) # And, 2012-10-02 12:03
workflow_hidden_field_v0.03.diff Magnifier (8.73 KB) # And, 2012-10-02 12:03

That is: two files with the same date and time.
Can I assume that these files are sorted in some way?
Maybe by version ascending (That is oldest file on top, newest at bottom)? Or maybe by version descending?

#11 Updated by # And almost 2 years ago

OK, thanks David Robinson. Unfortunately, I'm not familiar with Ruby language too. I'll check you advice later.

#12 Updated by # And almost 2 years ago

David Robinson wrote:

  1. And wrote:

David Robinson, latest.

Thank you # And for your prompt reply.
But I am affraid I see the following:

workflow_hidden_field.diff Magnifier (4.79 KB) # And, 2012-10-02 12:03
workflow_hidden_field_v0.03.diff Magnifier (8.73 KB) # And, 2012-10-02 12:03

That is: two files with the same date and time.
Can I assume that these files are sorted in some way?
Maybe by version ascending (That is oldest file on top, newest at bottom)? Or maybe by version descending?

Answer is very simple, I have not permissions to change order, or remove old patch attachment. So we get what we have.

#13 Updated by # And almost 2 years ago

David Robinson wrote:

That is: two files with the same date and time.
Can I assume that these files are sorted in some way?
Maybe by version ascending (That is oldest file on top, newest at bottom)? Or maybe by version descending?

And yes - latest attachments at bottom.

#14 Updated by Gurvan Le Dromaguet almost 2 years ago

Most recent version of my patch is 0.03, sorry I did not put any versioning in my first pulication.

#15 Updated by Peter Kalvin almost 2 years ago

Are you guys going to include this patch in 2.1.3 release? Would be awesome :)

#16 Updated by claude g almost 2 years ago

I did some tests - applied 0.03 patch and 2.1.0 (ok, not latest but it shouldn't have impact).
  • When clicking on update, hidden fields appear with content, it's editable and once done, it disappear from 'header' of the issue,
  • Hidden fields appear in mails notification,
  • Hidden fields modifications appears in history,
  • Hidden fields appear in issues tables, filter, columns..

So those fields are not completely hidden, is it wanted ? Can someone confirm those behaviour ?

#17 Updated by Gurvan Le Dromaguet almost 2 years ago

Thanks for your testing :)
No it's not wanted, dev is not complete and it looks like I have a bad condition somewhere, fields should not appear in edit :(

claude g wrote:

I did some tests - applied 0.03 patch and 2.1.0 (ok, not latest but it shouldn't have impact).
  • When clicking on update, hidden fields appear with content, it's editable and once done, it disappear from 'header' of the issue,
  • Hidden fields appear in mails notification,
  • Hidden fields modifications appears in history,
  • Hidden fields appear in issues tables, filter, columns..

So those fields are not completely hidden, is it wanted ? Can someone confirm those behaviour ?

#18 Updated by David Robinson almost 2 years ago

I have attached a patch file for what seems to work for me with History, Atom, CSV and PDF, I can't check mail notifications because I haven't got a working mail setup.
I have included a function to list attributes that are hidden on all statuses of all trackers on projects. This functions result can possibly be cached for efficiency...
The function is used to completely hide columns in the list of available columns and filters.

When revising the code please remember that I don't actually know Ruby, so have at it ;-)

#19 Updated by Jamie MacIsaac over 1 year ago

Does the above patch (workflow_hidden_field_DR_v0.04.patch) need either (or both) of the previous patches? I can apply workflow_hidden_field_DR_v0.04.patch on it's own, but the hidden field option doesn't show up (patch doesn't appear to modify app/helpers/workflows_helper.rb to add a "hidden" option like the other two patches do, so I assume one or both is required).

If I try applying one or both of the previous patches I get a load of "Reversed (or previously applied) patch detected! Assume -R?". Some of the hunks apply, but enough if them don't to make me think I've got something very wrong.

I've tried this in both the stable-2.1 and master branches.

#20 Updated by David Robinson over 1 year ago

Sorry Jamie MacIsaac I'm affraid some of the original patch was missing in my patch :-( I will try to upload a patch with all needed code ASAP, including a possible implementation for Mails which I've finally got running :-)

#21 Updated by David Robinson over 1 year ago

I've attached a new patch file with the missing code from the previous patch, and hidden fields in status mails.

Again, please be ruthless in the code review...

Also please note that a mail will be sent for each combination of hidden fields for the recipients, so in theory this could mean several mails need to be sent.
This could noticeably degrade performance for the end-user if mails are sent synchronously and the mail server is slow to respond.

#22 Updated by David Robinson over 1 year ago

There was a copy/pasta error in v0.05 I've attached a fixed patch.

#23 Updated by Terence Mill over 1 year ago

+1

#24 Updated by Jamie MacIsaac over 1 year ago

The patch (v0.06) applies cleanly to the current master branch (I'm using the GitHub official mirror, official SVN repo apparently not working just now?) but fails for me against current stable-2.1 (aka revision 10764, which is what the patches appear to be based on - see truncated output at bottom of post).

When I run against the master I can create issues (I even receive the email notification), but see an error (undefined local variable or method `position_name') when I try to display them (happens immediately after the issue is created).

Any idea what I'm doing wrong?

Patching against stable-2.1:
patching file app/models/mailer.rb
Hunk#3 FAILED at 66.
patching file app/models/query.rb
Hunk#2 FAILED at 365.
Hunk#5 FAILED at 927.

#25 Updated by David Robinson over 1 year ago

Jamie MacIsaac wrote:

The patch (v0.06) applies cleanly to the current master branch (I'm using the GitHub official mirror, official SVN repo apparently not working just now?) but fails for me against current stable-2.1 (aka revision 10764, which is what the patches appear to be based on - see truncated output at bottom of post).

When I run against the master I can create issues (I even receive the email notification), but see an error (undefined local variable or method `position_name') when I try to display them (happens immediately after the issue is created).

Any idea what I'm doing wrong?

Patching against stable-2.1:
patching file app/models/mailer.rb
Hunk#3 FAILED at 66.
patching file app/models/query.rb
Hunk#2 FAILED at 365.
Hunk#5 FAILED at 927.

Did you remember to upgrade the database? AKA: "rake db:migrate RAILS_ENV=production". Can you post the whole error?

#26 Updated by Jamie MacIsaac over 1 year ago

David Robinson wrote:

Did you remember to upgrade the database? AKA: "rake db:migrate RAILS_ENV=production".

Nope. Running the migration cleared up the error - thanks!

One of my colleagues has been testing the patch. All seems OK now, except none of the emails sent by the test Redmine server include a 'To:' field in the message envelope (no emails at all, not just emails for projects with hidden fields). Any ideas?

#27 Updated by David Robinson over 1 year ago

Jamie MacIsaac wrote:

One of my colleagues has been testing the patch. All seems OK now, except none of the emails sent by the test Redmine server include a 'To:' field in the message envelope (no emails at all, not just emails for projects with hidden fields). Any ideas?

The only thing I can think of is the "Blind carbon copy recipients (bcc)" configuration (under settings, e-mail notifications).

#28 Updated by @ go2null over 1 year ago

Duplicated by Feature #5011

#29 Updated by Jamie MacIsaac over 1 year ago

David - yep, the "Blind carbon copy recipients (bcc)" was indeed checked. Thanks for your help and the also for the patch - seems to be working fine.

#30 Updated by Terence Mill over 1 year ago

Please release with 2.2.0 it will make "Mightful workflow field enhancement" complete! ;)

#31 Updated by John Newlands over 1 year ago

Hi,

We have been testing the latest patch for 2 weeks now on our Development Redmine environment and have not found any new issues.

Is there any chance this could be put into 2.2.0

We are very keen to use this in our live Redmine however we have reservations about upgrading to a development branch.

Thanks

John

#32 Updated by John Moody over 1 year ago

I've applied the patch to my 2.1.4 installation, but it's now causing an error whenever I try to update an issue:

NoMethodError (undefined method `notified_users' for #<Issue:0x7f32dfc8faa0>):
app/models/journal_observer.rb:27:in `after_create'
app/models/journal.rb:47:in `save'
app/models/issue.rb:1269:in `create_journal'
app/models/issue.rb:903:in `save_issue_with_child_records'
app/models/issue.rb:890:in `save_issue_with_child_records'
app/controllers/issues_controller.rb:171:in `update'

The "notified_users" method is totally missing from the Issue model. Any thoughts? Thanks!

#33 Updated by Daniel Felix over 1 year ago

John Moody wrote:

The "notified_users" method is totally missing from the Issue model. Any thoughts? Thanks!

Hi there,

well this seems to be a defect installation.
Look at this: r10547
This Revision introduced the new method "notified_users". If this is totally missing in your model, your previous upgrades introduced this error. Please try to reupgrade your installation and try again.

Best regards,
Daniel

#34 Updated by ian stoddart over 1 year ago

Hi, I have been trying to apply this patch to a clean 2.1.4 installation.

I am getting errors similar to John Moody above.

Sorry if I am stating the obvious, but this v0.06 patch seems to depend on the private comment branch ( r10547 mentioned above from #1554 ) which seems to be targeted at the 2.2.0 release.

Do I need to upgrade to a later build than 2.1.4 to be able to apply this patch?

#35 Updated by ian stoddart over 1 year ago

Hi, updated my installation to 2.2.0.stable.10995 and the patch works fine after manually fixing one issue with mailer.rb.

Ian

#36 Updated by # And over 1 year ago

ian stoddart wrote:

Hi, updated my installation to 2.2.0.stable.10995 and the patch works fine after manually fixing one issue with mailer.rb.

Ian

Can you please patch the patch, for issue with mailer.rb? =)

#37 Updated by Wan Zhenhuan over 1 year ago

I would appreciate it so much guys if you could implement this in the next release!
Yeah, I saw tons of ppl want this feature to be integrated!

#38 Updated by Jamie MacIsaac over 1 year ago

And wrote:

Can you please patch the patch, for issue with mailer.rb? =)

Hi,

I'm not Ian, but I've "patched the patch" - workflow_hidden_field_DR_v0.07 applies cleanly to 2.2.0. The sole difference between v0.06 and 0.07 is on line 288 where "cc = issue.watcher_recipients - recipients" is replaced by "cc = journal.watcher_recipients - recipients" in app/models/mailer.rb. I'm pretty sure this is the issue ian stoddart refers to in 35 above.

#39 Updated by Terence Mill over 1 year ago

oh yeah, love it ;)

+1

#40 Updated by Daniel Felix over 1 year ago

Jamie MacIsaac wrote:

Hi,

I'm not Ian, but I've "patched the patch" - workflow_hidden_field_DR_v0.07 applies cleanly to 2.2.0. The sole difference between v0.06 and 0.07 is on line 288 where "cc = issue.watcher_recipients - recipients" is replaced by "cc = journal.watcher_recipients - recipients" in app/models/mailer.rb. I'm pretty sure this is the issue ian stoddart refers to in 35 above.

Hi Jamie,

thanks for providing this patch. I will test it tomorrow morning and give some quick feedback. Thanks for contribution!

#41 Updated by Daniel Felix over 1 year ago

Hi there,

this is working fine on r11165 for me.

In addition, I added a little patch for the german translation, if this patch is integrated.

Best regards,
Daniel

#42 Updated by ian stoddart over 1 year ago

Hi And,
Sorry, Ive not been watching this. I am not very familiar with generating a patch and didn't want to confuse matters by putting up a bad patch.

I believe the patch failed for me on 2.2.0 because the line numbers referenced in hunk # 3 in mailer.rb did not match and so the patcher could not work out where it should apply. All I did was manually find the correct lines of code and insert the hunk by hand.

Interestingly I am, now testing in more detail and have spotted that if I update a custom field which is hidden from some users, they still get an email informing that a change has happened, but the information the receive in the email shows no change. I would be happier if they did not get the email at all if the change affects a field they cannot see...

I am not sure if the issue Jamie has pointed out may or may not affect this?

#43 Updated by ilqar Caferov over 1 year ago

hi,

i use redmine stack (redmine-2.1.5 and redmine-2.1.6) . try patch with workflow_hidden_field_DR_v0.07.patch. there is no other plugin.

.
..
patching file app/models/mailer.rb
Hunk #3 FAILED at 66.
..
patching file app/models/query.rb
Hunk #2 FAILED at 365.
Hunk #3 succeeded at 405 (offset 58 lines).
Hunk #4 succeeded at 434 (offset -58 lines).
Hunk #5 FAILED at 927.
2 out of 5 hunks FAILED -
saving rejects to file app/models/query.rb.rej
..

what is wrong ?
Best Regards,
ilgar

#44 Updated by Daniel Felix over 1 year ago

ilqar Caferov wrote:

i use redmine stack (redmine-2.1.5 and redmine-2.1.6) . try patch with workflow_hidden_field_DR_v0.07.patch. there is no other plugin.

This will be your problem. The patch is for the current trunk, not for Redmine 2.1.6.
The linenumbers are different. You must apply this patch manually, but I won't guarantee that this patch will work on 2.1.6 instantly.

#45 Updated by Ramesh S over 1 year ago

Sorry if I am missing something obvious here, I just saw this thread and the "Related Issues" list is promising to have immediately :-) . I was looking for some information on what all features included into this patch being disussed here. Are there any information on what is included in this patch, other than going through the code? (I am not familiar with Ruby)

#46 Updated by Luiz Marcelo Serique over 1 year ago

Just to notify you all: I´ve successfully patched the 2.2.1.stable version.
I´m testing all the functionalities.
Good job!

#47 Updated by Ernesto Baschny over 1 year ago

Luiz, great news, keep us up-to-date please! Thanks for your work on that!

#48 Updated by ian stoddart over 1 year ago

Hi,

I am testing using patch 0.07 on 2.2.1.stable version.

I have some custom fields marked in the workflow / fields permissions as completely hidden for some roles.
When I log in as a user with one of these roles, the custom fields are hidden in the issue as expected.
If I open the issues page and expand the options to view available columns the completely hidden custom fields are available for selection and when they are selected the relevant data is displayed in the issues table.

I assume this is not expected behavior?
It makes the patch much less usable for my application as it is.

Everything else about the patch seems to be working great and if this one point is resolved then the patch is just what I need!

#49 Updated by ian stoddart over 1 year ago

Ok, now I understand. I had marked the custom field as hidden in all the states in use by the current issue type. The custom field was only used in one of the issue types.

For the custom field not to be displayed in the available columns list, the custom field needs to be hidden in all the states for all issue types.

I had missed that tickbox in the Workflow / Fields Permissions tab that hides statuses not in use for the current issue type.

#50 Updated by David Robinson over 1 year ago

ian stoddart wrote:

Ok, now I understand. I had marked the custom field as hidden in all the states in use by the current issue type. The custom field was only used in one of the issue types.

For the custom field not to be displayed in the available columns list, the custom field needs to be hidden in all the states for all issue types.

I had missed that tickbox in the Workflow / Fields Permissions tab that hides statuses not in use for the current issue type.

Thanks for the update Ian!
In the meantime while I was trying to reproduce the issue you mentioned, I have seen that there is an issue regarding this, columns, not values, showing, if you go to list issues without selecting a project first (so you're listing issues for all projects). I'm currently in the process of fixing this problem on our system, I will post a diff when done, if no one beats me to it.

#51 Updated by Daniel Felix over 1 year ago

  • Target version set to Candidate for next major release

I set this to a release candidate for the next major release. This could be a huge improvement for the worklow handling.

#52 Updated by David Robinson over 1 year ago

David Robinson wrote:

ian stoddart wrote:

Ok, now I understand. I had marked the custom field as hidden in all the states in use by the current issue type. The custom field was only used in one of the issue types.

For the custom field not to be displayed in the available columns list, the custom field needs to be hidden in all the states for all issue types.

I had missed that tickbox in the Workflow / Fields Permissions tab that hides statuses not in use for the current issue type.

Thanks for the update Ian!
In the meantime while I was trying to reproduce the issue you mentioned, I have seen that there is an issue regarding this, columns, not values, showing, if you go to list issues without selecting a project first (so you're listing issues for all projects). I'm currently in the process of fixing this problem on our system, I will post a diff when done, if no one beats me to it.

I have attached the above mentioned diff file.

I just want to mention again, that code review of any code I have submitted, is a very good idea, as I do not know Ruby nor the codebase, which means my code is very "*hackish*".

#53 Updated by David Robinson over 1 year ago

It seems I botched the diff file, it appears to be missing the changes from acts_as_watchable.rb

I have attached another diff file, hopefully with all the needed patches O_o

#54 Updated by ian stoddart over 1 year ago

Hi,

I am hitting an error:

ActionView::Template::Error (undefined local variable or method `detail' for #<#<Class:0x7f93a304de48>:0x7f93a337a0d0>):
    1: <% reply_links = authorize_for('issues', 'edit') -%>
    2: <% for journal in journals %>
    3:   <% if details_to_strings(journal.details).any? || journal.notes.blank? == false %>
    4:     <div id="change-<%= journal.id %>" class="<%= journal.css_classes %>">
    5:       <div id="note-<%= journal.indice %>">
    6:       <h4><%= link_to "##{journal.indice}", {:anchor => "note-#{journal.indice}"}, :class => "journal-link" %>
  app/helpers/issues_helper.rb:244:in `details_to_strings'
  app/helpers/issues_helper.rb:243:in `each'
  app/helpers/issues_helper.rb:243:in `details_to_strings'
  app/views/issues/_history.html.erb:3:in `_app_views_issues__history_html_erb__862122133_70136036374580'
  app/views/issues/_history.html.erb:2:in `each'
  app/views/issues/_history.html.erb:2:in `_app_views_issues__history_html_erb__862122133_70136036374580'
  app/views/issues/show.html.erb:128:in `_app_views_issues_show_html_erb__381019951_70136035944920'
  app/controllers/issues_controller.rb:119:in `show'
  app/controllers/issues_controller.rb:116:in `show'

I think it is down to details_to_strings in issues_helper.rb:

  # Returns the textual representation of a journal details
  # as an array of strings
  def details_to_strings(details, no_html=false, options={})
    ...

    ...
    values_by_field.each do |field_id, changes|
      unless detail.journal.issue.hidden_attribute?(detail.prop_key, options[:user])
        detail = JournalDetail.new(:property => 'cf', :prop_key => field_id)
        if changes[:added].any?
            detail.value = changes[:added]
            strings << show_detail(detail, no_html, options)
        elsif changes[:deleted].any?
            detail.old_value = changes[:deleted]
            strings << show_detail(detail, no_html, options)
        end
      end    
    end

on the second line detail is used before it is defined on the third line??

I am trying to get my head round what it should actually say, so thought I should post it here in the mean time as it might take me a while to work it out!

#55 Updated by David Robinson over 1 year ago

Hi Ian

Looks like it should be

      detail = JournalDetail.new(:property => 'cf', :prop_key => field_id)
      unless detail.journal.issue.hidden_attribute?(detail.prop_key, options[:user])        
        if changes[:added].any?
            detail.value = changes[:added]
            strings << show_detail(detail, no_html, options)
        elsif changes[:deleted].any?
            detail.old_value = changes[:deleted]
            strings << show_detail(detail, no_html, options)
        end
      end 

Where are you getting this? AKA: what did you do when you got the error?

Also more stuff, this time from pdf.rb, appears to be missing in my latest diff.

I have attached a diff, that includes both a fix for this error and the missing things from pdf.rb.

#56 Updated by ian stoddart over 1 year ago

Hi David,

thanks for the quick update.

I was updating the data in some custom fields in an issue. A number of the custom fields are hidden from many of the users. Some of these users are set to get email updates on any project change.
Does that help?

#57 Updated by ian stoddart over 1 year ago

Hi David,

sorry to report, if I make that change, I get an error when I try to display some particular tickets.

Started GET "/support/issues/300" for 10.xx.xx.xx at Tue Feb 12 14:20:20 +0000 2013
Processing by IssuesController#show as HTML
  Parameters: {"id"=>"300"}
  Current user: ian.stoddart (id=14)
  Rendered issues/_action_menu.html.erb (6.4ms)
  Rendered attachments/_links.html.erb (147.8ms)
  Rendered issue_relations/_form.html.erb (2.8ms)
  Rendered issues/_relations.html.erb (5.3ms)
  Rendered issues/_history.html.erb (1412.1ms)
  Rendered issues/show.html.erb within layouts/base (1667.6ms)
Completed 500 Internal Server Error in 1733ms

ActionView::Template::Error (undefined method `issue' for nil:NilClass):
    1: <% reply_links = authorize_for('issues', 'edit') -%>
    2: <% for journal in journals %>
    3:   <% if details_to_strings(journal.details).any? || journal.notes.blank? == false %>
    4:     <div id="change-<%= journal.id %>" class="<%= journal.css_classes %>">
    5:       <div id="note-<%= journal.indice %>">
    6:       <h4><%= link_to "##{journal.indice}", {:anchor => "note-#{journal.indice}"}, :class => "journal-link" %>
  app/helpers/issues_helper.rb:245:in `details_to_strings'
  app/helpers/issues_helper.rb:243:in `each'
  app/helpers/issues_helper.rb:243:in `details_to_strings'
  app/views/issues/_history.html.erb:3:in `_app_views_issues__history_html_erb__1110742084_70276145134480'
  app/views/issues/_history.html.erb:2:in `each'
  app/views/issues/_history.html.erb:2:in `_app_views_issues__history_html_erb__1110742084_70276145134480'
  app/views/issues/show.html.erb:128:in `_app_views_issues_show_html_erb__910177246_70276146378560'
  app/controllers/issues_controller.rb:119:in `show'
  app/controllers/issues_controller.rb:116:in `show'

If I comment out the 'unless' line and a matching end the it seems to behave fine.

If I read the first half of the function correctly, the 'values_by_field' has already been filled using an 'unless' clause, so is it required to do it again in the second half?

#58 Updated by David Robinson over 1 year ago

Hi Ian

I don't know, it appears that somehow detail.journal is nil after detail = JournalDetail.new(:property => 'cf', :prop_key => field_id) on line 245.

This seems very "wrong" to my untrained eyes when you take the following into consideration from journal_detail.rb

class JournalDetail < ActiveRecord::Base
  belongs_to :journal

I can't reproduce this on my system.

Can you tell me if there is something "special" about the issues that exhibit this behaviour?

Maybe detail.journal.issue isn't the right way to get to the right issue object in this function? Maybe someone with more knowledge about the codebase can chime in if they see this :-)

#59 Updated by David Robinson over 1 year ago

Or maybe it's just that I'm complete crap at getting these diff files right :-(

It seems that 0.010 still has the error with using detail before assignment

I have, yet again, attached a, hopefully, more correct diff file...

#60 Updated by ian stoddart over 1 year ago

Hi David,

I have been having a look and a think...

this only happens on a couple of issues.
The issues do have a large number of fields (almost 50), some fields are visible to all users (around 35), some fields are completely hidden from some of the users (around 15) (set as hidden in all the states for all issue types)

The changes that seem to have triggered the problem seem to be where I have made changes to issues where the only change was to fields which are completely hidden to some of the other users.

The thing I cannot understand is that I get the error if I log in as one of the users that cannot see the fields or as myself. When I log in as me I should be able to see these changes so I am not sure why the list would come back empty.

If I comment out the lines I mentioned then if I log in as me, I can see the complete history, if I log in as one of the limited users, then I just don't see the changes in the history at all. (this is what I would expect)

I will have more of a play and see if I can determine anything else about the particular issues.

#61 Updated by Daniel Felix over 1 year ago

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

This one should definitly find its way in 2.4.

#62 Updated by Jean-Philippe Lang over 1 year ago

  • Target version deleted (2.4.0)

I can't let people think that it will be added to 2.4.0. The patch has no test and I doubt that this feature will be added in a near future.

#63 Updated by Tobias Fischer over 1 year ago

Why that? Only because of a missing test?
This feature would be a huge improvement for workflows!

Think about an environment where customers are allowed to write tickets but shouldn't be bothered with categories, asignee or start/due date.
Do you really want to tell them just to ignore these fields? The "hide" option would be a killer feature for the most of us envolved in this thread...

Please, Jean-Philippe, give this a second chance!

#64 Updated by Daniel Felix over 1 year ago

Hi there,

I can understand both sides of the story.

On Jean-Philippes side...
I can understand that missing tests would make much trouble. The integration server couldn't handle a proper check if any feature is broken after a bug fix or a new feature implementation. This is a real problem. This will slow down the development and could cause buggy releases. Which is something, no one of us wants to have in the future, as Redmine is a real stable software in comparison to other project management tools.
The other thing is, that this patch has many points, some with a bigger impact. The patch has to be tested par excellence. There shouldn't be any side-effects by this patch.

On User side...
There are many products, even paid products, which give the user many many abilities to perform ticket tasks. Many abilities to visualize the workflow, many abilities to relate, plan, time issues and so on. But most of them has just one lack. They are horrible to maintain on the user side.
A project manager would love to have all this abilities. Maybe he could blind them out in his view. But a normal customer, who just adds an issue for the first time to the tracker, would be overwhelmed.

Jean-Philippe, just try to imagine (even if it's hard, as your quite long in the business, as the most us experienced PM's). You have bought a new coffee machine, everything is fine and ok. You used it every day. Maybe for two or three months. Then it's just wracked and you conduct the support to get a new one. The support aims you to the helpdesk (installed via Redmine, just for example). You see a mask, which holds up to 30 or 40 input fields. Some of them will be marked as required, but your not sure what they want in the input field labelled "QRS-Nr.". There are plenty of optional fields.
I'm sure, you just will fill all the required fields, as your not pretty sure, which of the optional fields is needed. After filling everything out, even the field QRS-Nr. - just in case you filled it with 1234, as it just accepts integer values and you don't know what they want and you won't call the rough support person again.
You send the request to the support. After two or three days (without coffee), you get the response.

"Your QRS-Nr. couldn't be found. Did you enter this Number? This Number is filled by the Helpdesk! More than that, you haven't filled the two optional fields [...].
We can't solve your request, until you've updated your request with the needed information!"

So... everything is "pretty". You go to the tracker, open the issue fields, type in everything needed and sent it to the support. The support fills all those fields after some days. You won't get any notification that your coffee machine is on the way to you. You just get some little hacky mails, which provides some strange information about different fields, such fields like the QRS-Nr.
These are all information, you just don't need. But you will be bothered with it.
Be honest, I'm sure you have such a situation before with some support. ;-)
Well I have such a situation in my daily business with many issue tracker or with some project management software. Just as an example, Microsoft Project, It provides the user with many menus and each of them differ slightly, depending on which object the user wants to add. But each of them has many fields, I don't use. Just for example, if I just plan a small project for myself or just a project which doesn't need a huge resource plan. Every Dialog asks me, which resource should be used. Which blows up the menus. If those menu would be more intelligent, and just display the resource options, If I have activated the resource plan, each dialog would be smaller and easier to manage.
Another example, currently we're using a self-made issue tracker, which should be replaced by Redmine. We have just 10 fields which are relevant for our daily business. Three are needed for each request, some are needed for special cases and some others are needed for our internal planning. All of them are revealed to our internal customers. They see, that many of them are useless for their request (our internal fields) they tend to just ignore all of those fields and just write plain text, which slows down our support. We need to manually check every issue and fill out all the needed fields. Just because, that there are to many fields they don't understand/use.

I'm sure, we could get a better solution than that! :-)

My suggestion...
#We evaluate the side-effects of this patch better. This task need some help of the community.
#We provide tests, which provide a good integration. This task need some help of the community, as the help of Toshi or Jean-Philippe, as you both are one of the experienced developers in the team and always provide good test cases.
#Maybe there could be a integration branch for this feature, which runs parallel to the normal 2.4 branch and will be merged with 2.4 or 2.5 if this integration is as stable as it should be.

Maybe this could be a way to please both sides?

#65 Updated by Max Horn over 1 year ago

I would love to see a feature like this in Redmine. Although I don't think it is a "killer feature", but certainly highly useful for certain use cases.

That said, from an engineering point of view, I have to agree with Jean-Philippe (for what little this may be worth). But I don't read him as rejecting this patch, nor does he say it's not important. His argument seems rather quite neutral and rational to me.

After all, there is an unresolved comment by Ian here, reporting issues with the patch. The author himself has stressed that he is new to Ruby, and that the code should hence be carefully reviewed (actually, I would hope that careful code review is undertaken for any submission).

As desirable as this feature is, I don't think it's good to import an untested, unreviewed implementation. What it if it introduces data corruption or if its design is broken (not that I have any indication for either)? Backing out a change is in general much harder than putting it in. A thorough set of tests would greatly help to alleviate these fears.

#66 Updated by Dipan Mehta over 1 year ago

It was very disheartening to know this patch is out from 2.4. I think this was very important functionality.

However, instead of getting into yes vs. no debate - I would like to ask what are the preconditions which will allow this patch to finally go in? What work is missing and what more that community can do to get this patch to the trunk in the fastest possible way?

#67 Updated by Anton Nepomnyaschih over 1 year ago

+80 people in our company =)

#68 Updated by VD DV over 1 year ago

+1
Looking forward to this functionality

#69 Updated by Anton Nepomnyaschih over 1 year ago

It seems, it doesn't work with 2.3 =(

#70 Updated by Wan Zhenhuan over 1 year ago

Hey, Daniel told me it will be available with 2.3, but it seems 2.3 came out without it?

#71 Updated by Anton Nepomnyaschih over 1 year ago

BTW, I've applied the last patch to 2.3 and everything works, except hidden column in issues list. Only issues_helper and query don't want to be patched. I've applied dirty JS hack to prevent the column shown. Temporary solution. Eager to see the feature in trunk.

#72 Updated by Max Horn over 1 year ago

This is not part of 2.3, if somebody told you differently, then they were mistaken resp. overeager. For details, please look at comment 62 (http://www.redmine.org/issues/12005#note-62) and the discussion following it.

#73 Updated by Yannick Recht over 1 year ago

Hi,

We are already intersted by this feature in my company.

#74 Updated by Dipan Mehta over 1 year ago

Another duplicate #13729

Just imagine how many people need this feature!! Please can we schedule this?

#75 Updated by Kamil . over 1 year ago

+1
I need to hide (disable?) watchers and file attachments

#76 Updated by David Robinson over 1 year ago

I completely agree with Jean-Philippe about everything (apart maybe from prioritizing this feature ;-), what I've made is a hack and should be treated as such.
I would love to do everything required to merge this feature, unfortunately I don't have the needed skills, it was a stretch for my non-existent Ruby knowledge to make the attached hack. I won't be able to acquire those skills in any reasonable time-frame either.
It is clear that if the Redmine community want this feature "soon" they will have to lift this burden themselves, someone from the community with the skills needed, will have to start doing this feature properly, so the Redmine team has an honest chance of merging a community created feature.
Either that or wait until the Redmine team finishes other, more important tasks, and get around to making this feature.

As Daniel quite clearly put it we as a community have the following tasks if we want this integrated soon:

#We evaluate the side-effects of this patch better. This task need some help of the community.
#We provide tests, which provide a good integration. This task need some help of the community, as the help of Toshi or Jean-Philippe, as you both are one of the experienced developers in the team and always provide good test cases.

If anyone with the needed skills are out there (Redmine System knowledge and/or Ruby knowledge and/or Test generation skills), and willing to work on this, please let yourself be known :-)

#77 Updated by Jai prakash about 1 year ago

will the patch allow to hide the default "status" field?

#78 Updated by David Robinson about 1 year ago

Jai prakash wrote:

will the patch allow to hide the default "status" field?

If you are referring to the attached "workflow_hidden_field_DR_v0.011.patch", the answer is no.

#79 Updated by Jai prakash about 1 year ago

@David
Yes I was referring to the patch.

#80 Updated by Jean-Philippe Lang about 1 year ago

Daniel Felix wrote:

Jean-Philippe, just try to imagine (even if it's hard, as your quite long in the business, as the most us experienced PM's). You have bought a new coffee machine, everything is fine and ok. You used it every day. Maybe for two or three months. Then it's just wracked and you conduct the support to get a new one. The support aims you to the helpdesk (installed via Redmine, just for example). You see a mask, which holds up to 30 or 40 input fields. Some of them will be marked as required, but your not sure what they want in the input field labelled "QRS-Nr.". There are plenty of optional fields.

You can actually make these fields read-only to the customer and they won't show up in the issue form.

I understand that this feature might be desirable but having to handle visibility per tracker and status is overcomplex IMHO and the patch does not seem to do it perfectly. Being able to set custom field visibility per role would be a nice improvement and a much more reasonable change to add in a next release. I'm reopening #5037 for 2.4.0, any feedback is welcome.

#81 Updated by Anton Nepomnyaschih about 1 year ago

I think, if there is possible to set read-only permission, then it should be also possible to set visibility also - it's logical: if you can't change a field, then maybe you also shouldn't see it sometimes.

But role-based visibility is enough for development process in our company now. So, I'm totally for the improvement in the next release =)

#82 Updated by David Robinson about 1 year ago

Jean-Philippe Lang wrote:

I understand that this feature might be desirable but having to handle visibility per tracker and status is overcomplex IMHO and the patch does not seem to do it perfectly. Being able to set custom field visibility per role would be a nice improvement and a much more reasonable change to add in a next release. I'm reopening #5037 for 2.4.0, any feedback is welcome.

Sounds very reasonable, and cool. I for one am all for closing this in favor of #5037.

#83 Updated by Ernesto Baschny about 1 year ago

Meanwhile #5037 has been resolved. But this only handles "custom fields" and not the "standard fields". So this is not at all what at least I need, because we don't use that much custom fields anyway. We still need a way to hide or make "read-only" standard fields for certain roles (i.e most commonly estimated time, target version, priority, assignee ...).

#84 Updated by Santiago Burgues about 1 year ago

++++++111

We use the estimated time field a lot and we don't want our customers to see the estimated time field because they will start making date calculations based on those estimates they see and that would be a huge problem to our planification.

Also, if we estimate that some task will take 8 hours but we charge the customer 10hs, say we use those 2hs for testing, we may let the customer know we are charging extra hours for testing but that's not always possible cause on low-budget projects the customer may respond that they will do the testing themselves so we don't charge them 2 extra hours, and that's not acceptable at all, I mean, not having time to test our work cause it would reduce our output's quality dramatically.

So, if the customer sees that we estimated it in 8hs and we charged them for 10 that would cause a instant complaint from to customer to our sales team.

You may say we can use a custom field for estimates but that won't work with any plugin that uses the estimated hours field to output reports.

Please reconsider adding this feature, it not only happens with that field I mentioned, due date is another controversial field we need to hide from the customer, the deliver plan is an entire different document (buffered) than the real estimation and internal delivery of the finished tasks.

Showing everything leaves us with too little room to play with the dates.

Thanks!

#85 Updated by Terence Mill about 1 year ago

Santiago Burgues wrote:

++++++111

We use the estimated time field a lot and we don't want our customers to see the estimated time field because they will start making date calculations based on those estimates they see and that would be a huge problem to our planification.

I a agree 100%!

Also, if we estimate that some task will take 8 hours but we charge the customer 10hs, say we use those 2hs for testing, we may let the customer know we are charging extra hours for testing but that's not always possible cause on low-budget projects the customer may respond that they will do the testing themselves so we don't charge them 2 extra hours, and that's not acceptable at all, I mean, not having time to test our work cause it would reduce our output's quality dramatically.

I agree to that sometimes customers cab't be convinced to accept taht testing is part of the job to make good products. However why do you don't just enter 10 hours because the estimation is not only for coding but anlyssis, sepcicfication, planning, coding testing <>bug fixing. Its an estimation for the whole buncg to bring th idea into production not only coding. Don't publish every steps estimation to ur customer. He is only interested in the final date and the final cost to get his feature on air.

So, if the customer sees that we estimated it in 8hs and we charged them for 10 that would cause a instant complaint from to customer to our sales team.

Don't confuse profit with costs, don't use this estimation field for sales.Either you have an conttact with ur customer ou ged paid per effort, so you just have to mulitply your spent time with ur hourl rate. Or you have a contract you get paid a fixed price for the outcome , which is mostly a release/version and is bargained after an estimation and pallning phase for the release. This will alos include possible risks and profits you wanna make with the job.

#86 Updated by Toshi MARUYAMA about 1 year ago

#87 Updated by Toshi MARUYAMA about 1 year ago

#88 Updated by Toshi MARUYAMA about 1 year ago

#89 Updated by Rick Boyer about 1 year ago

+1 for hiding time related fields!

This is a show-stopping issue for client access.

#90 Updated by Jeremy Bailey 12 months ago

+1

This is a show-stopping issue for client access.

Totally agreed. Or for corporate clients with mandates to only let people see what they need to see to get the job done.

#91 Updated by Diego Álvarez 12 months ago

+1

#92 Updated by Kos Kub 12 months ago

+1

#93 Updated by Pavel Potcheptsov 9 months ago

+1

#94 Updated by Stefan T. Oertel 8 months ago

+1

#95 Updated by Guillaume C 8 months ago

+1

#96 Updated by bilel kedidi 8 months ago

in Redmine 2.3.3, i had an error ( undefine method reject! in query.rb so, i changed @available_columns.reject! to available_columns.reject! and it works fine only in show information. but in edit or mail, we still find the hidden fields.

#97 Updated by Tobias Fischer 8 months ago

Please have a look at version 2.4 which resolved issue #5037 "Role-based issue custom field visibility"
In 2.4 you are now able to hide certain fields based on a role...

#98 Updated by Toshi MARUYAMA 7 months ago

  • Related to Feature #15782: Workflow Field Permissions - Status-Based Field Visibility added

#99 Updated by Gregor K 6 months ago

+1

#100 Updated by Dzianis Frydliand 6 months ago

+1

#101 Updated by Toshi MARUYAMA 5 months ago

#102 Updated by Juozapis Juozapauskiksi 5 months ago

+1 waiting to be released

#103 Updated by Pavel Potcheptsov 5 months ago

+1

#104 Updated by Łukasz Zaroda 5 months ago

+1 I used Redmine with client access in mind and realizing this feature is not here yet was a big let down :( .

#105 Updated by Dominique Lederer 5 months ago

+1

#106 Updated by Jeff W 5 months ago

+1
I would like to know this feature will comes with which version? As I can't see it in the roadmap.

#107 Updated by Gurvan Le Dromaguet 5 months ago

It can not at least because patch is not enough complete/clean/tested (See JP's arguments above) and also because JP considers it will give too much complexity to Redmine's administration.
I have merged it into my Redmine 2.4, will try to publish the patch but as of now it is combined with other customizations of mine not related.
That said, combined with Feature #14162, it is very powerful !

#108 Updated by Luis Serrano Aranda 5 months ago

+1

#109 Updated by André Bachmann 5 months ago

Gurvan Le Dromaguet wrote:

It can not at least because patch is not enough complete/clean/tested (See JP's arguments above) and also because JP considers it will give too much complexity to Redmine's administration.
I have merged it into my Redmine 2.4, will try to publish the patch but as of now it is combined with other customizations of mine not related.
That said, combined with Feature #14162, it is very powerful !

Is it possible to implement this feature as a plugin? This would solve the problem that Jean-Philippe Lang doesn't want this feature in Redmine itself.

#110 Updated by Gurvan Le Dromaguet 5 months ago

André Bachmann wrote:

Is it possible to implement this feature as a plugin? This would solve the problem that Jean-Philippe Lang doesn't want this feature in Redmine itself.

It would be the best surely. I have never done a plugin yet and not expert at ruby/rails. I will 1st publish the 2.4 patch, and maybe with the help of the community - who has already turned my initial patch into something more consistent - we will get this done :)

#111 Updated by Łukasz Zaroda 5 months ago

http://www.redmine.org/plugins/redmine_hide_estimated_hours there is also this plugin as a workaround for some use cases. Seems to work well.

#112 Updated by Gurvan Le Dromaguet 5 months ago

Łukasz Zaroda wrote:

http://www.redmine.org/plugins/redmine_hide_estimated_hours there is also this plugin as a workaround for some use cases. Seems to work well.

Looks like working "role based" not "workflow based". Then this is implemented in 2.4 for Custom fields, so this plugin is a "complement" of #11963, but not what we try to implement here.

#113 Updated by David Robinson 5 months ago

For anyone using the attached patch, derivatives thereof, or intending to, I just became aware that "priority" hiding doesn't work. All occurrences of "issue.hidden_attribute?('priority')" should be replaced with "issue.hidden_attribute?('priority_id') for that to work.

#114 Updated by David Robinson 5 months ago

Gurvan Le Dromaguet wrote:

I have merged it into my Redmine 2.4, will try to publish the patch but as of now it is combined with other customizations of mine not related.

That would be awesome. We're currently limited to running old versions of Redmine, because we haven't been able to afford the resources needed to update the patch. So this would be a big help, at least for us!

#115 Updated by Gurvan Le Dromaguet 5 months ago

Did it fast and not tested, but this is a start, attached patch for redmine 2.4.2

#116 Updated by Richard Gunn 5 months ago

Hiding of standard fields based on role and tracker is a must for anyone who wants to provide client access to Redmine.

I created a customer specific role & user and edited their permissions (role and workflow) to hide time related fields.The correct behavior is exhibited for this user under this role creating/updating issues - no time related fields are shown. However when viewing the issue as this user the start date, due date, % done and estimated time is visible, as is the history related to this. Additionally, the role constraints do not flow through under issues -> options -> columns list: the due date, estimated time and % done are visible, can be selected & added as columns onto the issue list although the user's role disables all time tracking

There have been so many similar requests (mine is Issue #16095 ). Is the demand for this feature not enough to be considered as core to the product ?

It is very frustrating that this is only issue preventing us from providing role based customer access to Redmine.

#117 Updated by Ilkka Koutonen 5 months ago

+1 This would be very good addition

#118 Updated by Oscar Corsvall 5 months ago

I tried the patch for 2.4.2 but i get this error when applying it?
Hunk #1 FAILED at 25.
1 out of 1 hunk FAILED -- saving rejects to file app/helpers/workflows_helper.rb.rej
patching file app/models/project.rb
patching file app/models/workflow_permission.rb
Unreversed patch detected! Ignore R? [n] y
patching file app/models/issue.rb
Unreversed patch detected! Ignore -R? [n] y
Hunk #1 succeeded at 503 (offset 20 lines).
Hunk #2 succeeded at 544 (offset 20 lines).
patching file app/views/mailer/_issue.text.erb
patching file app/views/mailer/_issue.html.erb
patching file app/views/issues/show.html.erb
Hunk #1 FAILED at 33.
1 out of 1 hunk FAILED -
saving rejects to file app/views/issues/show.html.erb.rej
patching file config/locales/en.yml
Hunk #1 succeeded at 889 (offset 1 line).
patching file lib/redmine/export/pdf.rb

#119 Updated by Gurvan Le Dromaguet 5 months ago

Oscar Corsvall wrote:

I tried the patch for 2.4.2 but i get this error when applying it?

Thanks for trying ... and sorry for the issue, I will have a try and come back

#120 Updated by Oscar Corsvall 5 months ago

Hi!

Is there any way to remove that patch?
It seems to create issues when i try to create or update a issue.
I get "Internal error"

And log says:
Completed 500 Internal Server Error in 182.2ms

ActionView::Template::Error (undefined local variable or method `user' for #<#<Class:0x0000000712d408>:0x00000007139a50>):
2: <%= issue_url >
3:
4: * <
=l(:field_author)%>: <%= issue.author >
5: <
unless issue.hidden_attribute?('status', user) >
6: * <
=l(:field_status)%>: <%= issue.status >
7: <
end >
8: <
unless issue.hidden_attribute?('priority', user) %>

#121 Updated by Gurvan Le Dromaguet 5 months ago

Oscar Corsvall wrote:

Hi!

Is there any way to remove that patch?

svn revert if you do not have other modifications.

#122 Updated by David Robinson 5 months ago

Oscar Corsvall wrote:

Hi!

Is there any way to remove that patch?

If you aren't using any SCM:
If you don't have any other changes in those files, you could just download them again, and overwrite.

#123 Updated by David Robinson 5 months ago

I've attached a patch for v2.4.4 (r12953) that appears to work on my system. It has only been very lightly tested, so beware.

#124 Updated by Tobias Fischer 5 months ago

To remove changes introduced by a patch you can revert a patch!

To reverse the patch, use the patch command with the -R option:

patch -p1 -R < path/file.patch

(If your patch was applied with the -p0 option, use that instead.)

#125 Updated by Oscar Corsvall 5 months ago

Anyone tested it on redmine 2.5.0?

#126 Updated by David Robinson 4 months ago

I have gotten around to a bit more testing, and Line 843 must be:

recipient_groups[variations.index(hidden_attribute_names(user) + (custom_field_values - visible_custom_field_values(user))] << user

otherwise you cannot create or edit issues.

Is there anyone around with experience with plugins that might be able to spare some time to try to convert this to a plugin. I can lend any desired assistance.

#127 Updated by minkbear minkbear 4 months ago

+1 for this feature

#128 Updated by Doan Phuoc about 1 month ago

how i use path file for edit ???

#129 Updated by Andre Greeff about 1 month ago

Doan Phuoc wrote:

how i use path file for edit ???

I assume you meant "patch" not "path"..? It's in the Redmine wiki pages.

#130 Updated by Michael Sanders 8 days ago

The above patch workflow_hidden_fields_redmine2.4.4_v1.01.patch did not completely for me with the following specs:
Redmine version 2.5.1.stable
Ruby version 2.0.0-p481 (2014-05-08) [x86_64-linux]
Rails version 3.2.17
Environment production
Database adapter Mysql2

Here are the steps I took to apply:

[root@redmine redmine-2.5.1]# patch -p0 < workflow_hidden_fields_redmine2.4.4_v1.01.patch
(Stripping trailing CRs from patch.)
patching file app/helpers/issues_helper.rb
Hunk #1 succeeded at 241 (offset 7 lines).
Hunk #2 succeeded at 248 with fuzz 2 (offset 7 lines).
Hunk #3 succeeded at 268 (offset 7 lines).
(Stripping trailing CRs from patch.)
patching file app/helpers/workflows_helper.rb
(Stripping trailing CRs from patch.)
patching file app/models/issue.rb
(Stripping trailing CRs from patch.)
patching file app/models/issue_query.rb
(Stripping trailing CRs from patch.)
patching file app/models/journal.rb
(Stripping trailing CRs from patch.)
patching file app/models/project.rb
(Stripping trailing CRs from patch.)
patching file app/models/query.rb
Hunk #2 succeeded at 342 (offset 2 lines).
Hunk #3 FAILED at 776.
1 out of 3 hunks FAILED -- saving rejects to file app/models/query.rb.rej
(Stripping trailing CRs from patch.)
patching file app/models/workflow_permission.rb
(Stripping trailing CRs from patch.)
patching file app/views/issues/_history.html.erb
(Stripping trailing CRs from patch.)
patching file app/views/issues/show.html.erb
(Stripping trailing CRs from patch.)
patching file app/views/mailer/issue_edit.html.erb
(Stripping trailing CRs from patch.)
patching file app/views/mailer/issue_edit.text.erb
patch unexpectedly ends in middle of line
[root@redmine redmine-2.5.1]# /etc/init.d/httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd: [Thu Jul 24 11:38:19 2014] [warn] NameVirtualHost *:80 has no VirtualHosts
                                                           [  OK  ]

After application, the Issues page would give an internal server error. Here is the information from the log:

Started GET "/issues?page=7&set_filter=1&sort=tracker%253Adesc%252Cstatus%252Csubject%253Adesc" for 66.249.67.250 at 2014-07-24 13:58:40 -0400
Processing by IssuesController#index as */*
  Parameters: {"page"=>"7", "set_filter"=>"1", "sort"=>"tracker%3Adesc%2Cstatus%2Csubject%3Adesc"}
  Current user: anonymous
Completed 500 Internal Server Error in 115.4ms

NameError (undefined local variable or method `hidden_fields' for #<IssueQuery:0x007f60c7f2fc90>):
  app/models/query.rb:346:in `available_filters'
  app/models/query.rb:229:in `build_from_params'
  app/models/issue_query.rb:119:in `build_from_params'
  app/helpers/queries_helper.rb:175:in `retrieve_query'
  app/controllers/issues_controller.rb:56:in `index'

Also available in: Atom PDF