Feature #12005
openMightful workflow field enhancement: hide
90%
Files
Related issues
Updated by # And almost 12 years ago
Yes, all copyrights goes to Gurvan Le Dromaguet. Thanks, man.
Updated by Peter Kalvin almost 12 years ago
I would appreciate it so much guys if you could implement this in the next release. Thank you in advance :)
Updated by David Robinson almost 12 years ago
+1
Which one of the attached files is the newest?
Updated by Daniel Felix almost 12 years ago
It would be quite useful to have this feature in the next release!
+1
Updated by David Robinson almost 12 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.
Updated by David Robinson almost 12 years ago
- 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?
Updated by # And almost 12 years ago
OK, thanks David Robinson. Unfortunately, I'm not familiar with Ruby language too. I'll check you advice later.
Updated by # And almost 12 years ago
David Robinson wrote:
- 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:03That 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.
Updated by # And almost 12 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.
Updated by Gurvan Le Dromaguet almost 12 years ago
Most recent version of my patch is 0.03, sorry I did not put any versioning in my first pulication.
Updated by Peter Kalvin almost 12 years ago
Are you guys going to include this patch in 2.1.3 release? Would be awesome :)
Updated by claude g almost 12 years ago
- 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 ?
Updated by Gurvan Le Dromaguet almost 12 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 ?
Updated by David Robinson almost 12 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 ;-)
Updated by Jamie MacIsaac almost 12 years 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.
Updated by David Robinson almost 12 years 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 :-)
Updated by David Robinson almost 12 years 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.
Updated by David Robinson almost 12 years ago
There was a copy/pasta error in v0.05 I've attached a fixed patch.
Updated by Jamie MacIsaac almost 12 years 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.
Updated by David Robinson almost 12 years 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?
Updated by Jamie MacIsaac almost 12 years 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?
Updated by David Robinson almost 12 years 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).
Updated by Jamie MacIsaac over 11 years 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.
Updated by Terence Mill over 11 years ago
Please release with 2.2.0 it will make "Mightful workflow field enhancement" complete! ;)
Updated by John Newlands over 11 years 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
Updated by John Moody over 11 years 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!
Updated by Daniel Felix over 11 years 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
Updated by ian stoddart over 11 years 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?
Updated by ian stoddart over 11 years 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
Updated by # And over 11 years 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? =)
Updated by HU an over 11 years 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!
Updated by Jamie MacIsaac over 11 years 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.
Updated by Daniel Felix over 11 years 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!
Updated by Daniel Felix over 11 years ago
- File translation_de.diff translation_de.diff added
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
Updated by ian stoddart over 11 years 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?
Updated by ilqar Caferov over 11 years 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). saving rejects to file app/models/query.rb.rej
Hunk #4 succeeded at 434 (offset -58 lines).
Hunk #5 FAILED at 927.
2 out of 5 hunks FAILED -
..
what is wrong ?
Best Regards,
ilgar
Updated by Daniel Felix over 11 years 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.
Updated by Ramesh S over 11 years 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)
Updated by Luiz Marcelo Serique over 11 years ago
Just to notify you all: I´ve successfully patched the 2.2.1.stable version.
I´m testing all the functionalities.
Good job!
Updated by Ernesto Baschny over 11 years ago
Luiz, great news, keep us up-to-date please! Thanks for your work on that!
Updated by ian stoddart over 11 years 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!
Updated by ian stoddart over 11 years 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.
Updated by David Robinson over 11 years 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.
Updated by Daniel Felix over 11 years 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.
Updated by David Robinson over 11 years 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*".
Updated by David Robinson over 11 years 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
Updated by ian stoddart over 11 years 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!
Updated by David Robinson over 11 years 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.
Updated by ian stoddart over 11 years 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?
Updated by ian stoddart over 11 years 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?
Updated by David Robinson over 11 years 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 :-)
Updated by David Robinson over 11 years 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...
Updated by ian stoddart over 11 years 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.
Updated by Daniel Felix over 11 years ago
- Target version changed from Candidate for next major release to 2.4.0
This one should definitly find its way in 2.4.
Updated by Jean-Philippe Lang over 11 years 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.
Updated by Tobias Fischer over 11 years 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!
Updated by Daniel Felix over 11 years 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?
Updated by Anonymous over 11 years 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.
Updated by Dipan Mehta over 11 years 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?
Updated by Anton Nepomnyaschih over 11 years ago
It seems, it doesn't work with 2.3 =(
Updated by HU an over 11 years ago
Hey, Daniel told me it will be available with 2.3, but it seems 2.3 came out without it?
Updated by Anton Nepomnyaschih over 11 years 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.
Updated by Anonymous over 11 years 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.
Updated by Yannick Recht over 11 years ago
Hi,
We are already intersted by this feature in my company.
Updated by Dipan Mehta over 11 years ago
Another duplicate #13729
Just imagine how many people need this feature!! Please can we schedule this?
Updated by Kamil . over 11 years ago
+1
I need to hide (disable?) watchers and file attachments
Updated by David Robinson over 11 years 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 :-)
Updated by Jai prakash over 11 years ago
will the patch allow to hide the default "status" field?
Updated by David Robinson over 11 years 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.
Updated by Jai prakash over 11 years ago
David Crow
Yes I was referring to the patch.
Updated by Jean-Philippe Lang about 11 years 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.
Updated by Anton Nepomnyaschih about 11 years 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 =)
Updated by David Robinson about 11 years 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.
Updated by Ernesto Baschny about 11 years 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 ...).
Updated by Santiago Burgues about 11 years 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!
Updated by Terence Mill about 11 years 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.
Updated by Toshi MARUYAMA about 11 years ago
- Related to Feature #14162: Hidden Fields - Role Based added
Updated by Toshi MARUYAMA about 11 years ago
- Related to deleted (Feature #14162: Hidden Fields - Role Based)
Updated by Toshi MARUYAMA about 11 years ago
- Has duplicate Feature #14162: Hidden Fields - Role Based added
Updated by Rick Boyer about 11 years ago
+1 for hiding time related fields!
This is a show-stopping issue for client access.
Updated by Jeremy Bailey about 11 years 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.
Updated by bilel kedidi over 10 years 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.
Updated by Tobias Fischer over 10 years 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...
Updated by Toshi MARUYAMA over 10 years ago
- Related to Feature #15782: Workflow Field Permissions - Status-Based Field Visibility added
Updated by Toshi MARUYAMA over 10 years ago
- Related to Feature #15918: Managing "description" field added
Updated by Juozapis Juozapauskiksi over 10 years ago
+1 waiting to be released
Updated by Łukasz Zaroda over 10 years ago
+1 I used Redmine with client access in mind and realizing this feature is not here yet was a big let down :( .
Updated by Jeff W over 10 years ago
+1
I would like to know this feature will comes with which version? As I can't see it in the roadmap.
Updated by Gurvan Le Dromaguet over 10 years 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 !
Updated by André Bachmann over 10 years 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.
Updated by Gurvan Le Dromaguet over 10 years 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 :)
Updated by Łukasz Zaroda over 10 years 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.
Updated by Gurvan Le Dromaguet over 10 years 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.
Updated by David Robinson over 10 years 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.
Updated by David Robinson over 10 years 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!
Updated by Gurvan Le Dromaguet over 10 years ago
- File workflow_hidden_fields_redmine2.4_v1.0.patch workflow_hidden_fields_redmine2.4_v1.0.patch added
Did it fast and not tested, but this is a start, attached patch for redmine 2.4.2
Updated by Richard Gunn over 10 years 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.
Updated by Ilkka Koutonen over 10 years ago
+1 This would be very good addition
Updated by Oscar Corsvall over 10 years 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 saving rejects to file app/views/issues/show.html.erb.rej
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 -
patching file config/locales/en.yml
Hunk #1 succeeded at 889 (offset 1 line).
patching file lib/redmine/export/pdf.rb
Updated by Gurvan Le Dromaguet over 10 years 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
Updated by Oscar Corsvall over 10 years 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) %>
Updated by Gurvan Le Dromaguet over 10 years ago
Oscar Corsvall wrote:
Hi!
Is there any way to remove that patch?
svn revert if you do not have other modifications.
Updated by David Robinson over 10 years 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.
Updated by David Robinson over 10 years ago
- File workflow_hidden_fields_redmine2.4.4_v1.01.patch workflow_hidden_fields_redmine2.4.4_v1.01.patch added
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.
Updated by Tobias Fischer over 10 years 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.)
Updated by Oscar Corsvall over 10 years ago
Anyone tested it on redmine 2.5.0?
Updated by David Robinson over 10 years 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.
Updated by Anonymous about 10 years 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.
Updated by Michael Sanders about 10 years 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'
Updated by Michael Sanders about 10 years ago
Still having trouble with this. Any help is appreciated.
Updated by Anonymous about 10 years ago
Michael Sanders wrote:
Still having trouble with this. Any help is appreciated.
One thing that may make a difference to you....
Michael Sanders wrote:
The above patch workflow_hidden_fields_redmine 2.4.4 _v1.01.patch did not completely for me with the following specs:
samir djouadi version 2.5.1.stable
...
I don't have a 2.4.4 setup available to test with, but I have a feeling that's why the patch isn't working for you.
Updated by Alex Wais almost 10 years ago
Hello everybody,
I made a plugin for this based on the previous patches. Seems to work well under 2.5.2.
Git repo: https://github.com/alexwais/redmine_workflow_hidden_fields
Feel free to contribute.
Updated by Tomasz O over 9 years ago
Alex Wais wrote:
I made a plugin for this based on the previous patches. Seems to work well under 2.5.2.
Git repo: https://github.com/alexwais/redmine_workflow_hidden_fields
Hi Alex,
Do you have any plans about porting this plugin to latest versions of Redmine?
I have just upgraded to 2.6.1, and it does not work,
I am getting error:
Web application could not be started cannot load such file -- tcpdf (LoadError) /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in `require' /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in `block in require' /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:236:in `load_dependency' ....
Maybe there is a quick fix that I could apply by myself?
Regards,
Tomek
Updated by Mischa The Evil over 9 years ago
@Everyone: please don't start discussions about referenced plugins in this issue. Keep those in the plugin author's issues. This issue is about a Redmine core feature request and should be used to discuss how a proposed change like requested could be specified, designed and finally implemented in a clean, clear, resource-efficient, tested and maintainable way.
Tomasz O wrote:
Alex Wais wrote:
I made a plugin for this based on the previous patches. Seems to work well under 2.5.2.
Git repo: https://github.com/alexwais/redmine_workflow_hidden_fields[...]
I have just upgraded to 2.6.1, and it does not work,
[...]
Maybe there is a quick fix that I could apply by myself?
Tomasz Truszkowski: now that I'm already responding, take a look at the dedicated issue in the plugin's GitHub repo and the therein referenced commit on a fork of the plugin. This seems to fix compatibility with 2.6.x.
Disclaimer: I haven't used nor tested this plugin and the referenced patches.
Updated by Eric Lemanissier almost 9 years ago
+1
When will this feature be available for redmine 3 ?
Updated by Christopher Caruk almost 9 years ago
+1 here too... this would be incredibly useful!
Updated by Vincent Robert about 8 years ago
It may help: I have just created a very simple plugin which lets you hide core fields, based on roles.
More details here:
http://www.redmine.org/plugins/redmine_customize_core_fields
Updated by Yoel Unanue Mac Lenman about 8 years ago
Hello Vincent, functionality is very interesting, but I can not access the settings , gives me " page not found" when I access http:// miredminehost/core_fields. can you help mi
Vincent Robert wrote:
It may help: I have just created a very simple plugin which lets you hide core fields, based on roles.
More details here:
http://www.redmine.org/plugins/redmine_customize_core_fields
Updated by Go MAEDA about 7 years ago
- Has duplicate Feature #11490: Permissions for roles to see fields per tracker/status added
Updated by Marius BĂLTEANU over 5 years ago
- Related to Feature #3088: Estimated hours field able to hide role based added
Updated by VD DV over 5 years ago
It is core fuctionality that makes redmine more functional for serious redmine installations with mixed external and internal redmine users working on same projects.
Is this feature planned in next redmine versions?
Updated by Bernhard Rohloff over 5 years ago
+1
I'm looking forward to see this realized in a future Redmine version.
Updated by Lorenzo Meneghetti about 3 years ago
This task is actually very simple for custom fields.
It may be that I have never fully understood the request but in my eyes the possibility of hiding a custom field in the views is very simple since the function that does it already exists during custom field editability calculations.
So a few months ago I wrote a simple patch with a custom field setting flag "Hide if read only in workflow" that hide that field in the show if in the workflow is daclred as read_only.
I did it for Issues but it shouldn't be difficult to extend it to other entities custom fields.
Thanks
Lorenzo
Updated by David Robinson about 3 years ago
Yeah, the logic is quite simple for custom fields, unfortunately non-custom ("core") fields are treated very differently in many parts of the code.
I cannot say why this is so, but it is.
Updated by David Robinson over 2 years ago
Any chance somebody on the Core team (Go Maeda? Marius Balteanu?) might look at this?
The fact that "Core" fields and Custom-fields are treated so differently makes maintaining a plugin for this functionality pretty complicated.
It would be really nice if the base system simply treated core fields on par with custom-fields, allowing plugin authors to customize core fields just like custom fields.
Right now all views that use core fields have to be specifically patched for every new release if you make a plugin that touches core fields.
Maybe it would be better if I create a separate issue for "unifying" core/custom field logic?