View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005081||mantisbt||feature||public||2005-01-07 05:35||2019-01-29 02:07|
|Target Version||Fixed in Version|
|Summary||0005081: Assigning multiple persons to an issue|
many projects require multiple persons to be involved in solving an issue, where mantis allows only one person to be assigned.
this would be a huge advantage.
|Tags||No tags attached.|
|related to||0010207||feedback||Allow multiple valids emails address per account (patch attached)|
|has duplicate||0004252||closed||thraxisp||Assigning an issue to more then one person|
|has duplicate||0004782||closed||thraxisp||Ability to assign bugs to groups rather tha individuals|
|has duplicate||0006727||closed||thraxisp||Direct a bug to several users.|
|has duplicate||0007863||closed||giallu||Allow an issue to be assigned to multiple developers|
|has duplicate||0006530||closed||giallu||Assign issue to several account|
|has duplicate||0009499||closed||giallu||assign problem to multiple users|
|has duplicate||0010266||closed||vboctor||Assign bug to more users?|
|has duplicate||0010885||closed||giallu||Assign issues to more than one developers or a developper-group|
|has duplicate||0017090||closed||atrol||Multiple assignments|
|has duplicate||0020304||closed||atrol||Multiple user in same work profile|
|has duplicate||0022592||closed||atrol||MANEJO DE UN GRUPO DE USUARIOS|
|has duplicate||0025393||closed||atrol||Allow Reporters to Assign an issue to multiple Users at the same time.|
|related to||0006644||closed||grangeway||Patch for multiple developers per issue|
|child of||0006470||closed||vboctor||Features for Mantis 2.0|
Hmm, would a "user group" concept work here (i.e., assign an issue to one user group, which contains a group of users who are related in some way)? That might achieve the same results without impacting the ease of use of the package for those that don't need to assign issues to multiple users.
well, not exactly. my teams are usually working with different person-configurations (in task 1 A works with B, but for task 2 a works with D). and since the teams are 7-10 persons, making a group for each configuration would be nonsense.
hello... user GROUPS is not what i need. any comment on this one?
Hmm, if user groups are not the answer here then 0004782 is not a duplicate of this issue.
If you want to be able to pick multiple assignees on a per-issue basis, this would probably require replacing the handler_id field in mantis_bug_table with an additional table containing user_id and bug_id values (like mantis_bug_monitor_table).
User groups would probably require a table containing a group name and user_id values.
i really like this idea and would like to see both, multiple user assigements and the possibilty to create groups and then assign the group to the issue and everyone in the group have the issue in his assigement list
may any news from the responsible persons?
any news? team mantis - hello? :)
this feature is of substantial value to me and i think i am not the only one.
Implementing this feature requires a significant amount of effort. This is due to the fact that Mantis source assumes that there is always one handler for an issue. This is the case in the GUI, filters, view issues, print issues, csv export, email notifications, access rights, ...etc.
The other issue is that having multiple responsible persons may make Mantis more complicated or slower for people who do not need the feature.
I have been thinking of a compromise that doesn't involve a lot of work and also that partially achieves what you want to do. I couldn't find a reasonable one. The only thing that you can now do, is to have custom fields that are automatically populated by the developers list. In this case you can have multiple people on the issue, however, have the current person that is actively working on the issue as the current handler.
The other option is to create child tasks from the current task and assign each child task to a developer. This is assuming that the work to be done by each person is clear and can be documented in a child issue.
Looking forward for your comments.
i'm not saying it is easy, i am only saying this is important.
imagine quite a big project, where we have horizontal responsibilities. in my team i most often have let's ssay 3 developers working on a feature: 1 on GUI, 1 on business logic and 1 in DB. i get a change request from the customer and all i know is that it is feature X. now what i need to do is assign all of them to this change request, because i have scant idea where the change will be (GUI, business logic, DB).
assigning groups won't help, because they are NOT STATIC! they are dynamic, even during a couple of day period and i have a number of developers.
creating subtasks won't help because only the developers know who will actually make a change within the small feature-team.
additional fields won't help because in this case i would have the main handler (assigned one) and the supporting ones (those in additional fields). and what about all the features like email notofications etc.?
i know its many work, but i have nothing to add, godziu told all the important things, and also my thoughts about this topic.....its really needed i guess
any progress on this topic? It would really help to work witb BT
Just some of my thoughts (as I've worked on development teams, managed them, and now am a Senior Management Consultant at one of the 'Big 4').
Because you have such dynamic teams, try some non-technical solutions from an organisational behaviour standpoint.
This technique has alot of positives:
Outline the role very clearly.
Yea, I know it's work. But the payoff will be worth it (see above). If you are only looking at $$ results, think how much time you will save by delegating - then apply your salary, sales potential, customer relationship building opportunities to this additional free time.
Remember that in small teams, technical answers to communication and management challenges are rarely the best.
P.S. If you use this, make sure you do proper and open feedback from your staff as the best of intentions may not be enough to overcome abrasive communication.
Long winded I know, but I hope it helps.
Thoughts on usergroups:
Suggestion (godziu, how about this?): ability to assign one master-handler to a bug who is the actual team-leader for this one; and assign several sub-handlers who get emails about it. The teamleader is the one responsible, even if he deligates work to others.
Perhaps (for the time being) you could use the Monitor function for this. Convention in your project would be that the teamleader sends a couple of reminders to the other developers so they're automatically set as monitors. Montiors would be handlers to the bug.
I didn't care much for the workaround with email-groups; not very elegant to solve a mantis shortcoming in the mailer.
added again + 5 $ to sponsorship, cause i still think the initial request is the only "clean and effectiv" solution.
"ability to assign multiple persons to a bug, and groups"
thank you guys for solutions and suggestions.
as for the Change Leader, it is my Lead Developer who owns the change actually. he/she assigns the change to whoever is needed (HERE is the problem) and he/she verifies the solution (of chooses a "verifier").
as for monitoring: guys, a change may be a 2 hours of work issue. there is no time for monitoring and part-time solutions.
a CLEAN solution is needed.
mantis team: HELP! :)
hello team mantis...
any plans concerning this feature? :)
Godziu, if you assign the same issue to 3 persons... who decide when the issue is resolved ?
I believe in using child task for each, even if there is nothing to do for one of them... each developer resolve his own task (even saying there was nothing to do for him) and when all tasks are resolved, so the mother task can be solved.
I don't believe in a working solution with the same task affected to more than one person.
We are using a "workaround":
One person is responsible for the problem! Other developers are involved by monitoring a problem. This can be done very easy by sending a reminder to the develloper (This is a default feature which can be switched of in the config_inc.php!)
On the other side every one can add notes to a bug (like me in this case).
guys... we are going in circles...
1) if a task is assigned to 3 persons, the person who decides it is his/her bug resolves it; I have project oriented, responsible developers - they know they have to correct bugs; as a backup - I have the lead developer or someone similar - but we want to MINIMIZE his/her role
2) one person responsible for the problem: guys, I need a mechanizm for choosing such a person! at the beginning we don't know who the person is.
You can create a task (not affected) and use reminder to "build" the team.
When a developper of the team find there's an impact, he creates a child of the first task. Thisk child issue is affected to him.
When all of the child issues are resolved, the mother can be set resolved.
I have no plans to implement this as part of the standard Mantis, at least for the moment. I think some of the users who commented on the issue also agree that this is not a typical case. I would say that support for groups and assigning an issue to a group will eventually be added to Mantis. However, as you made it clear, this won't satisfy your requirement.
Sorry for that.
Reminder sent to: steffi
I think cloning is not a good idea because one strengh of mantis is to keep all information centralized (per case). Now you have to check all copys for changes...
When you clone an issue, it is still linked back to the original. Keeping a master = parent and clone = child relationship will add a message when you try to resolve the parent without resolving the children.
My sponsorship is actually for user groups, not multiple-users. I agree with gtomlin's suggestion that 0004782 is not really a duplicate of this, but the discussion has clearly moved here so I am going along with that.
My users discovered Reminders and Monitoring on their own and this works fairly well for us as a solution to the dynamic-multiple-assignee problem, when we need it.
One thing I would do with user groups is auto-assign new issues to a group of reviewers and have them all share the workload, then turn things over to a group of workers and have them also share the load. Ideally it would not force the status to 'assigned' unless the assignee is a single person, so I do not have every issue showing up purple.
There are also a lot of delegated administration features I would like to have that require a group concept first. I have tried to simulate some of these by creating subprojects to match the groups I had in mind, but that is a poor fit.
Been watching this discussion, and I posted the original request for user groups (0004782)
I've worked on a small patch that doesn't solve the exact issue but allows the reporter of a bug to add users as monitors whilst the issue is being created. Those users are e-mailed when the bug is submitted.
Check out: 0006128
Sorry I can't understand an issue.
If an issue is BIIIiiiG need to make child issues and make a task as you are project manager.
And assigner of parent issue is responsible for fixing.
When there are many assigner, no one responsible. And as result no one feel it's pressure of a bug.
As a summury try to use child issues, for fixing subcomponents. Must be one person who responsible - ASSIGNER of the issue.
No? Explain me.
As a feature make chekbox for parent issue "notificate when child change". Almost as says MattB.
I never see "Big" issues that fixed only by wide enough team.
For fixing such issue need a component method for it.
That way you will see when each person make its part for fixing THE ISSUE.
Three observations (mainly to Godziu):
1) For the majority of projects, a bug is the responsibility of a single person. He or she can use other resources or transfer the responsibility. In most projects, the responsibility is not shared. As was said before: If many people are responsible, no-one feels responsible. This really is a well-proven way: it is the way most projects work.
2) Implications, implications. The change you request looks small and innocent enough, but I fear it may have MAJOR implications on the way Mantis behaves. If this would be implemented, there will be a very large list of exceptions where a bug's status is changed to another state in some cases, but not in others.
3) An impact-analysis of this change has never been made. You will find that even a small impact-analysis raises a whole batch of questions about how Mantis should behave if some users agree on something, but others don't.
I read again all of it. Draw drafts of all problems. And can't understand needs in this issue.
Imagine next situation:
Let's imagine another situation:
The first situation is an example when manager don't what to look into bugs and think that developers will resolve it by himself.
The Managers (or CL - change leader) that not dive into bug. I call and will call bad managers. (If project is big I say about lover manager or project manager. defenition depend).
So the conclusion is.
I alredy suggest in forum make for mantis templates of using exactly in manual.
P.S. See my previous posts for example if issue is really big.
!!!P.S. Can someone remove this discussion into forum?
To mgerben: sorry for the confusion about my double negative. I said that I wanted the status to NOT be set to assigned unless the assignee was a single user.
Translation: I would like assigning to a group to leave the status alone, but assigning to a user to set it to assigned. However I recognize not everyone will want this so it probably needs to be configurable, just as it is already configurable (g_auto_set_status_to_assigned) whether the status is set.
I disagree with the assertion that only assigning something to a specific person convinces them to work on it. Assigning to a group really should mean that everyone in the group is expected to volunteer to work on issues, and when doing so they assign the issue specifically to themselves.
The whole point of this is to share the workload of reviewing new/feedback items, and dispatching acknowledged/confirmed items. I have a large number of volunteers who do not have a lot of spare time, so I am trying to make the most of the hours they do have in which they are motivated to work. Some of our people are assign-happy and this has often resulted in bugs sitting around being ignored by the person they were supposedly assigned to, because that person never agreed to do the work and doesn't feel obligated to do anything just because somebody thought they should be the one to work on it.
I have started training some people to look for red/yellow items and try to move those along, but without the extra association provided by some kind of assignment, this is more poll-itensive and thus people are less motivated because they have to check yet another website in addition to the forums and mailing lists they already check (or don't, as is often the case).
I can still make this work if assigning to the group slams the status field to assigned, but the coloring of the issue displays is far less useful.
Personally I agree that allowing a bug to be assigned to muliple users and to have group control would both be great features.
I thought I would suggest a work around for anyone who really needs this feature now, in case you hadn't already thought of it.
Create a new user "group1", with group1 encompassing users developerA and developerB. So that the developers get the email notification configure your email server to forward group1@ email to developerA@ and developerB@.
This should allow you to cover most of the facilities that you want, email notification to the team and the responsibility of the issue is assigned to the team as well.
Not the most elegant solution, but hopefully this should help some people wanting groups. Technically this can also be set up to cover all permutations of teams, so if you do not have set groups, but alternating groups specific to each task then you can set this up in the same way. Of course if you have a lot of developers then this can get very messy with a large number of email groups required.
1)Not wanting to stick my finger in the problem but already doing so....
It's working perfectly at our company. And I'd love to have that feature in Mantis as I'm trying to bring Mantis into our company and this is the most missed feature which is only party compensated by the "Allow multiple Viewers on Assignment"-Patch offered here...
this will make mantis only miss a couple of features from peregrine and other top notch ticket reporting systems.
I've coded a quick hack for this problem for 1.0.0RC5. You're free to try and comment, but please read the disclaimer :=)
I just thought it interesting to note that Eventum has the ability to assign issues to multiple owners. This was actually one reason we did NOT CHOOSE Eventum. Mantis' notion of a single handler for an issue matches my organizations concept of ownership.
If Mantis does select to add such a feature, I hope it is done in a manner which includes the current, single owner behavior. I do like the observations others have made regarding parent/child issues.
I agree with the Eventum comment.
I don't mind to assign a bug to one person who can then deligate it to someone else.
If everybody is responsible, nobody is accountable.
I agree, that it is better not to have multiple people own an issue.
I could imagine, that there would be group support, so that I could pool the issues by needed skills. And then programmers could pick issues from the pool / group they belong to.
How would that be?
Just to clarify: I didn't want to propose to let that become the only option for mantis, I just provided the patch so that other people who have the same needs as I did can use it. In our case, we only got about 5 developers working in a team. In this closed team, we've done good with not assigning the bug to specific people, but to all who have an idea about the topic of the bug.
If you read the forum entry, you'll see that this patch is not made in a way that it can be applied to the main mantis tree or anything..
We've solved this by making 1 parent issue, clone the parent & add details - 1 for each person involved, and adding a relationship between the parent & children.
PARENT -> Assigned to: SELF (the reporter) OR to a project manager.
Each issue to be fixed is usually unique, and only ONE person should be ultimately responsible for fixing THAT issue. This is one of the GREAT things with Mantis. 2 colleagues/users/developers/whatever, cannot blame eachother for NOT fixing the issue, ergo; only ONE person is responsible.
When several 'smaller' issues (children) is part of one bigger issue (parent), either the reporter, a project manager or a senior developer checks that the child issues really are resolved; then being able to resolve the parent issue.
We don't have any "misunderstandings" anymore. ("A thought B fixed the problem in issue NNN - and vice versa", etc). Therefore, I suggest: 1 issue per person. Group them if necessary.
In order to have something like this, I developed the tasks plugin which allows for assigning tasks to various other developers.
Hi, I'm back using Mantis again after a few years of no one caring, we last used Mantis heavily in 2005 (v1.0.0rc1 !). I'm configuring 1.2.2 now and just donated $100 as I expect this to be a lifesaver since we have our yearly event coming up in about two months.
I like a lot of what's been done since 1.0 ... especially project inheritance which seems to be the one feature to rule them all now. In fact it's almost powerful enough to make user groups irrelevant. In fact I would say that a (sub)project with no categories defined or inherited is for all practical intents and purposes a user group.
This time around I am going to set up our Mantis install using project inheritance and composition so that all my desired user groups map to one of the (sub)projects. Then I can turn off auto-assignment status changes and use assignment to "" to indicate that something is on a shared queue and somebody in that (sub)project is supposed to claim it and work on it.
If this works out well, then I would consider my interest in this issue addressed.
Apparently not. Users are not yet inheritable. Nice job on categories though.
The task plugin has been updated to allow automatic tasks to be allocated to various developers.
Do we have any updates on the development of this feature? If not, I might take a look at solving this, but it may require more then a plugin to address it.
Happy to help,
To my knowledge, noone in the team is currently working on this. If you feel like implementing this feature, please feel free to submit a pull request against the master branch on Github.
Does anyone know the list of all of the scripts that call for the assigned user?
I'm sure your friend grep does ;)
Well i've been recently working on a project, assigning multiple people. I've found nothing in forums, so i've started to change in codes and managed to do so!
Basically what i did was to cancel assign to button and instead of assign to, i just made one more "monitor list" and renamed to "assign users" and make lots of changes in code part. I managed it to work. If you are still having issues of assigning multiple people, i'd be happy to send my codes.
Have a nice day :)
If you can combine all your changes into a plugin, it could be usefull.
Well i'm kinda new to Mantis. Only been using for 3 weeks now. So i don't know how to make a plugin but i will look into it
Can someone help me with this?
Hi, this issue is resolve? where can i find the plugin for mantisbt 2.3.1? Best regarts.
do we have any workaround for that (patch - Plugin) or good news for implementation
As far as i am aware, there is nothing new available. The Task module is still available also for version 2.x
|2005-01-07 05:35||godziu||New Issue|
|2005-01-07 09:42||gtomlin||Note Added: 0008890|
|2005-01-09 07:24||godziu||Note Added: 0008896|
|2005-01-09 07:25||godziu||Sponsorship Added||godziu: US$ 5|
|2005-01-09 07:25||godziu||Sponsorship Total||0 => 5|
|2005-01-09 09:13||thraxisp||Relationship added||has duplicate 0004252|
|2005-01-09 09:14||thraxisp||Relationship added||has duplicate 0004782|
|2005-01-17 06:11||godziu||Note Added: 0009044|
|2005-01-17 10:11||gtomlin||Note Added: 0009047|
|2005-01-17 11:33||thomaskm||Note Added: 0009048|
|2005-01-17 11:34||thomaskm||Sponsorship Added||thomaskm: US$ 5|
|2005-01-17 11:34||thomaskm||Sponsorship Total||5 => 10|
|2005-01-27 10:41||thomaskm||Sponsorship Updated||thomaskm: US$ 10|
|2005-01-27 10:41||thomaskm||Sponsorship Total||10 => 15|
|2005-01-27 10:42||thomaskm||Note Added: 0009119|
|2005-01-31 06:29||godziu||Note Added: 0009150|
|2005-01-31 07:28||vboctor||Note Added: 0009151|
|2005-02-01 07:55||godziu||Note Added: 0009162|
|2005-02-01 07:57||godziu||Sponsorship Updated||godziu: US$ 10|
|2005-02-01 07:57||godziu||Sponsorship Total||15 => 20|
|2005-02-01 08:45||thomaskm||Note Added: 0009163|
|2005-02-14 18:09||thomaskm||Note Added: 0009311|
|2005-02-14 19:52||Matt_wc||Note Added: 0009313|
|2005-02-15 03:09||mgerben||Note Added: 0009318|
|2005-02-15 03:20||mgerben||Note Edited: 0009318|
|2005-02-15 03:22||mgerben||Note Edited: 0009318|
|2005-02-17 07:00||hinke||Sponsorship Added||hinke: US$ 5|
|2005-02-17 07:00||hinke||Sponsorship Total||20 => 25|
|2005-02-17 19:07||thomaskm||Sponsorship Updated||thomaskm: US$ 5|
|2005-02-17 19:07||thomaskm||Sponsorship Total||25 => 20|
|2005-02-17 19:07||thomaskm||Sponsorship Updated||thomaskm: US$ 15|
|2005-02-17 19:07||thomaskm||Sponsorship Total||20 => 30|
|2005-02-17 19:09||thomaskm||Note Added: 0009332|
|2005-02-21 17:50||godziu||Note Added: 0009357|
|2005-02-21 17:50||godziu||Sponsorship Updated||godziu: US$ 15|
|2005-02-21 17:50||godziu||Sponsorship Total||30 => 35|
|2005-03-07 05:53||godziu||Note Added: 0009489|
|2005-03-07 15:20||malaussena||Note Added: 0009495|
|2005-03-09 02:57||djockheck||Note Added: 0009501|
|2005-03-09 16:47||godziu||Note Added: 0009504|
|2005-03-10 00:42||malaussena||Note Added: 0009505|
|2005-03-11 06:51||vboctor||Note Added: 0009513|
|2005-03-27 15:32||steffi||Note Added: 0009666|
|2005-03-30 02:27||djockheck||Note Added: 0009682|
|2005-05-11 07:43||hinke||Sponsorship Deleted||hinke: US$ 5|
|2005-05-11 07:43||hinke||Sponsorship Total||35 => 30|
|2005-05-11 12:33||thraxisp||Note Added: 0010089|
|2005-08-08 19:19||toddpw||Sponsorship Added||toddpw: US$ 15|
|2005-08-08 19:19||toddpw||Sponsorship Total||30 => 45|
|2005-08-08 20:50||toddpw||Note Added: 0011126|
|2005-08-11 12:29||MattB||Note Added: 0011174|
|2005-08-12 12:53||demon||Note Added: 0011194|
|2005-08-12 13:01||demon||Note Added: 0011195|
|2005-08-15 03:39||mgerben||Note Added: 0011211|
|2005-08-15 05:04||demon||Note Added: 0011212|
|2005-08-15 22:27||toddpw||Note Added: 0011219|
|2005-11-09 04:41||ag||Note Added: 0011604|
|2005-11-09 04:42||ag||Note Edited: 0011604|
|2005-11-10 17:03||ramonklown||Note Added: 0011609|
|2005-11-10 17:07||ramonklown||Note Edited: 0011609|
|2005-11-15 02:37||bobeid||Sponsorship Added||bobeid: US$ 10|
|2005-11-15 02:37||bobeid||Sponsorship Total||45 => 55|
|2005-12-02 10:19||McWizard||Note Added: 0011682|
|2005-12-03 09:32||ramonklown||Note Added: 0011687|
|2005-12-07 08:26||jlatour||Status||new => acknowledged|
|2005-12-07 08:34||jlatour||Relationship added||child of 0006470|
|2006-01-27 07:52||McWizard||Note Added: 0012027|
|2006-01-28 00:44||mlovell||Note Added: 0012032|
|2006-01-28 00:46||mlovell||Note Edited: 0012032|
|2006-01-28 08:00||mgerben||Note Added: 0012035|
|2006-01-28 08:57||moppel||Note Added: 0012037|
|2006-01-28 11:20||McWizard||Note Added: 0012038|
|2006-02-17 21:09||thraxisp||Relationship added||has duplicate 0006727|
|2007-03-30 04:06||giallu||Relationship added||has duplicate 0007863|
|2007-06-20 20:11||vboctor||Relationship added||related to 0006644|
|2008-08-07 04:07||giallu||Relationship added||has duplicate 0006530|
|2008-08-07 04:10||giallu||Relationship added||has duplicate 0009499|
|2009-03-31 02:09||siebrand||Relationship added||related to 0010207|
|2009-06-11 19:15||vboctor||Relationship added||has duplicate 0010266|
|2009-08-28 10:15||giallu||Relationship added||has duplicate 0010885|
|2009-12-16 08:01||RoboDoc||Note Added: 0023914|
|2010-09-03 09:23||cas||Note Added: 0026567|
|2010-09-14 00:53||toddpw||Note Added: 0026708|
|2010-09-15 21:51||toddpw||Note Added: 0026726|
|2010-09-15 23:59||huanhvhd||Sponsorship Added||huanhvhd: US$ 10|
|2010-09-15 23:59||huanhvhd||Sponsorship Total||55 => 65|
|2011-02-14 00:16||sibijohnmathew||Sponsorship Added||sibijohnmathew: US$ 10|
|2011-02-14 00:16||sibijohnmathew||Sponsorship Total||65 => 75|
|2011-02-14 06:49||papaya||Sponsorship Added||papaya: US$ 50|
|2011-02-14 06:49||papaya||Sponsorship Total||75 => 125|
|2011-02-21 08:00||cas||Note Added: 0028270|
|2011-02-21 08:01||cas||Note Edited: 0028270||View Revisions|
|2011-08-26 20:35||TheDarkKnight||Note Added: 0029564|
|2011-08-28 19:42||dregad||Note Added: 0029579|
|2011-08-30 13:37||TheDarkKnight||Note Added: 0029599|
|2011-08-31 04:33||dregad||Note Added: 0029602|
|2011-12-14 03:20||rombert||Severity||major => feature|
|2012-07-26 02:18||ekahraman||Note Added: 0032373|
|2012-07-27 02:56||cas||Note Added: 0032380|
|2012-07-27 07:14||ekahraman||Note Added: 0032383|
|2014-03-13 15:55||atrol||Relationship added||has duplicate 0017090|
|2015-07-06 04:26||sasha2002||Note Added: 0051017|
|2015-11-23 15:00||atrol||Relationship added||has duplicate 0020304|
|2017-03-28 17:03||atrol||Relationship added||has duplicate 0022592|
|2017-07-21 10:31||fdromero||Note Added: 0057284|
|2018-09-27 05:12||titovetch||Note Added: 0060698|
|2018-09-27 06:25||cas||Note Added: 0060699|
|2019-01-29 02:07||atrol||Relationship added||has duplicate 0025393|