|Allow Administrators to edit comments|
|We are planning to allow selective editing of posted comments. First iteration will allow administrators to use this functionality, in the future it will probably be configurable via roles. Screenshots are to demonstrate this feature in action.|
1. Users will see final version of the content
2. There is an Edit icon in the comment's header for administrators
3. When the icon is clicked, standard editor comes up.
When comment was edited, the list of revisions is displayed in the header (for admins only).
4. Initial revision is displayed
5. Actual revision is displayed
6. Difference between revisions #1 and #2
|Kirill Bondar ||Matthew Hesse||Gerrald Voerknecht|
|Gert-Jan Bakelaar||Caroline Berrie||Boris Heuer|
Caroline Berrie 10/21/2008 9:49:19 AM
We have had several occurrences where two clients have access to a central product area and one client has accidentally uploaded a file containing sensitive information which they don't want the other client to see. Would it be possible for only admins to be able to delete files so that we have a way of resolving this issue without having to open a new issue, copying the relevant information and deleting the original issue?
Caroline Berrie 12/23/2008 9:24:33 AM
It would be good if admin users were able to edit the text in posted issues so they can fix typos etc...
John Kuhn 12/23/2008 11:26:26 AM
Not sure what this means; I am an admin on our BUGtrack and I can edit issues. Perhaps your permissions have been "tweaked" not to allow that?
Caroline Berrie 12/24/2008 3:05:39 AM
I mean allow the admin to be able to edit already posted issues. At the moment you can edit an issue but it adds a new post. What I want to be able to do is to fix e.g. typos that a colleague or client has made in a previous post. I'm aware that there are risks involved with editing an earlier post due to the audit trail which is why I think this should only be available to admin users.
John Kuhn 12/24/2008 10:22:06 AM
Oh, of course. Everyone needs to learn how to use the spell check button.
Miguel Berrozpe 1/3/2009 11:58:02 AM
I'm not sure whether this is a good idea. IMHO, typos are an "acceptable" flaw in the history of a bug, issue, or otherwise. But "tampering" into the contents of past records would be not acceptable, depending on the related business processes. We use bugtrack for issue/incident management in construction and facilities business, and it would be disastrous to allow anybody (even the administrator) to manipulate in any form past records of team work. I assume that all other fields of application may have similar concerns.
Miguel Berrozpe 1/3/2009 12:40:48 PM
I think that rather than allowing any "deletion" (in our company, no user, not even an administration or a manager, may delete or "manipulate" any established record), the issue pointed out by Caroline should be resolved through the very popular topic of the "private comments".
In other words, it should be possible that some of the history record (without being deleted or tampered) of a bug or issue is made visible to certain users, roles, or groups of users only.
Gerrald Voerknecht 3/22/2010 5:40:50 PM
Well I agree with the poster of this. It is quite normal to have the possibility to edit already posted issues. An audit trail would give the neccessary info in that case. Many times a bug is not written completely and new programmers have to read the whole history, even if 80% of the given info is not relevant anymore. If like Miguel doesn't want this, make a checkbox to enable or disable editable history. I do like this bugtracksystem a lot and I was just using this for two hours now. But because I can not edit the first posted text anymore (I just pressed the Save button by accident e.g. or just want to add some extra info which you need when you START reading...) not possible unfortunately. Altough this system has it all.. this feature is a must have for me. So I will google again to find another system which is as easy as this one... but with the ability to edit the first message-texts. I don't understand John by the way who says he can edit the messages... I can't... Once posted... Always be there....
John Kuhn 3/22/2010 5:48:35 PM
The existing workflow is correct, you can click 'edit' after the initial issue is posted and clarify or update anything that was not intended. It maintains a strong chain of custody. If you need to edit something to ensure it is pretty before you post it in BUGtrack, use Word.
Kirill Bondar 3/22/2010 9:07:36 PM
By "Edit" John means he can add new entries to an issue discussion.
Everyone is right... to the certain extent.
Typos are hardly a problem, but premature comment submissions or submissions of classified information are pain.
However, consider the following:
1. Other parties are notified by email immediately. Even if you correct your comment afterwards they'll receive initial version anyway.
2. If you wrote the comment, and someone else commented it, and then you edited yours, will another comment still be relevant? Would not this create even more mess?
Perhaps we could allow the user to edit his/her entry if it is a last one, or to edit an entry within short timeframe: 10 minutes, half an hour or something like that.
-- BT Team
Gerrald Voerknecht 3/23/2010 3:28:41 PM
That's the thing... espacially when working with offsite members, discussions and explanations are done thru typing updates to the issue. But if after reading 7 updates to a ticket 80% of the text was getting useless because of misunderstanding te bug or whetever reason you would like to edit the original item (my opinion of course). Editing half an hour etc is useless in those cases. Just create an admin setting 'allow editting of postings by ...' -> choice "Nobody", "Original Issuer", "a specific role" Than everybody will be happy I suppose. I have found an alternative tool, but thats for sure a lesser alternative in user interface. BugTrack is much better in most things! But editing the current postings is mandatory for me. Thanks
Matthew Hesse 4/16/2010 10:00:57 AM
We have two issues related to this:
We have a whole class of third parties who are expected to enter tickets, but many are reluctant to do so for fear that other third parties will "snoop around" looking at their posts (e.g., they don't want to look foolish for posting something that was already a known issue or wasn't a bug at all). The private comments option only imperfectly addresses this.
If, however, third parties ignore the requirement to *not* post PII (personally identifiable information) we Admins *must* retain the capacity to remove these. Federal privacy laws dictate that we be responsible for due diligence. At this point I have to delete the entire ticklet and re-post everything EXCLUDING the mistakenly posted PII.
Perhaps, to address the issue concerning not wanting anyone to have a "super-user" capacity to Delete, how about being able to selectively HIDE? This would address legal requirements, then, if, e.g., records had to be subpoenaed, that the information can't have "gone missing".
Matthew Hesse 7/29/2010 2:02:07 PM
I just posted this as a comment on another idea exchange ticket, thinking I had already promoted this a long time ago, but apparently I only suggested it behind the scenes to BUGtrack staff. So here goes...
There are a few discussions on the board regarding the (often statutory) need to maintain electronic record integrity, while at the same time allow for the judicious (and, again, often statutory) need to EDIT. Both needs, from a legal standpoint, are potentially significant (with potentially costly legal repercussions) but they are not necessarily mutually exclusive.
Example: If someone posts PII (personally identifiable information), I need to edit it out in accordance with Privacy regulations (HIPAA, FERPA, COPPA, Gramm-Leach Bliley, etc.), but at the same time I have to maintain electronic record integrity for audit compliance. As a State Agency, I had better figure out a way to comply!
I have "problem users" from different regions posting *names* instead of IDs, when other regions' users (who are, necessarily, in the same user/role/class) have no legitimate business reason to see them. If I can't remove the "disallowed content" I'm jeopardizing those individuals' privacy.
This means--short of some "Administrative Edit" capacity--I have no way to protect the privacy of an individual other than to delete the entire ticket and re-post it with the PII content edited out.
This has become a huge burden on me as an Admin. It is more burdensome when the PII occurs much later on the ticket, especially when several attachments have already been uploaded in earlier posts, &/o tickets have been interlinked: I then have to first download and save attachments in order to re-upload them to the new (edited) ticket, and I also have to re-edit any /linked/ tickets to note where the new links are pointing.
From the highest-level view, an Admin user's ability to Delete an entire ticket is in itself effectively an "integrity" issue, so--as with all of these regulations--it all comes down to the "due diligence ... performed in accordance ... within reason" clause that's typically embedded in most of these statutes.
We do need to be able to easily reflect all changes for integrity purposes, but we also need to put the necessary Admin Edit capacity in the hands of those Admins duly tasked with privacy and security compliance.
The only way I know to do this is to employ an NTK-style metadata capacity at the database level to allow Admin users a view of the content that regular users cannot see. When an Admin edits a ticket, the original data do not get deleted, only deleted from all other users' view. The edited content, now “managed” by surrounding it with a metadata tag effectively indicating "Admin access only" (ex: <AdmOnly>edited content</AdmOnly>) is then “skipped” by the content display routine, and no longer visible to regular users.
Problem solved! :-)
Matthew Hesse 9/15/2010 7:56:45 AM
I know this is now in development, but in response to Kirill's comment on 3/22:
I used the native BUGtrack parameters to prevent text/attachments from being distriburted via email. Instead, only the URL to the posted ticket is displayed. This prevents any PII/unwanted info from being transmitted "in the clear" or retained in electronic format.
Of course, if the edit (i.e., by the Admin) does not occur almost immediately, users can theoretically receive the email link and click through to (and capture) the content rather quickly.
Using a strict "moderated" approach to prevent this, while effective, requires far too much interactivity (and diligence!) on the part of the moderator, and stifles the immediacy of the collaboration/workflow. I suppose this is where an admin must decide whether to set up penalties for violations, even removal off account access for repeat violators.
Kirill Bondar 9/15/2010 9:28:06 AM
228 - allow admin users to edit messages so they can fix typo's etc...
284 - Admin-only edit function
Matthew Hesse 9/15/2010 9:51:23 AM
Great, Kirill! I can't wait to test it... :-)
Kirill Bondar 10/12/2010 10:13:44 AM
226 - Allow an admin to be able to delete a file
Kirill Bondar 10/13/2010 8:05:44 AM
Kirill Bondar 1/24/2011 5:07:27 PM
Just got "Notify Users when a post is edited
". Thus, follow up: should other (non-admin) users be notified about admin edits?
For non-admins the notification might be misleading since they do not see the indication the post was edited - unless we provide the link to particular comment.
LARCHE, Simone 2/2/2011 8:29:30 AM
From my point of view having this feature has been a huge advantage. I normally don't edit the request - only the title so that it makes sense. Users rarely define their request successfully and I find that giving it a good title helps with reporting. Carry on editing....
As for notifications - do our users get notified at the moment if we edit their entries? I don't think they need to be. Usually it's to correct spelling or identify it better.
Kirill Bondar 2/2/2011 10:49:04 AM
@Simone > do our users get notified?
They don't get notified. That's why we raised this discussion.
IMHO, they do not need to, as "admin edit" should be normally used for patching some text in comment - and not for rewriting it entirely.
Matthew Hesse 3/16/2011 6:45:34 AM
Everyone should keep in mind that if you are using the default email notification, all content will be distributed in the body of the email. Since email is transmitted in clear text, any sensitive content is thus at risk of interception. Even if not intercepted, it is by default distributed to all initial recipients (i.e., anyone in a given work group attached to a support-type email distribution) &/o anyone already linked to an existing ticket (again, dependent on whether you have configured notification beyond the default settings).
We have changed our email notification settings to include only the hyperlink to the ticket. This prevents content distribution (including attachments) via mail, but allows vigilant Admins (or other designated project managers) to link out and review content at the earliest possible opportunity, thus mitigating the risk of exposure. That allows for your "due diligence" clause. In our state, we have a Breach Notification policy requiring us to notify any individuals whose personal information may have been exposed, so this functionality was especially important for us to be able to leverage.
Thanks again to Kirill and team for putting the effort into this!
|Back to Search Results|