|Summary:||RFE: Add kerberos id of user who created a topic as a search field.|
|Product:||[Community] PressGang CCMS||Reporter:||Tim Hildred <thildred>|
|Status:||MODIFIED ---||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||731902|
Description Tim Hildred 2012-04-03 00:38:43 UTC
It would be handy to have the kerberos ID of the author who created a topic to be a search condition. Furthermore, it would also be handy to have the kerberos ID of the author who most recently, or originally, edited the XML for a topic separately searchable.
Comment 1 Tim Hildred 2012-04-03 00:40:25 UTC
As a follow on possibility, where there is an "assigned writer" tag, maybe it could default to the kerberos id of the writer who creates a topic.
Comment 2 Matthew Casperson 2012-07-10 03:43:55 UTC
This should be captured by envers when a topic is created or edited.
Comment 3 Lee Newson 2014-01-15 02:50:12 UTC
Added in 1.4-SNAPSHOT build 201401151219 There are now two additional query fields in the Topic and Content Spec search REST api: "createdBy" and "editedBy". Each field will do an exact match as doing a like query cannot be optimized enough to actually be efficient. Example call: http://localhost:8080/pressgang-ccms/rest/1/topic/get/query;createdBy=lnewson; Additionally these fields are exposed in the UI on the respective "fields" page under the "Edited By" and "Created By" text boxes. Note: This will only do a search where the user details were supplied to the REST api. As such since the UI always sends the "Unknown" user this may not be of much help until that information is accurately captured using Authentication mechanisms. Note 2: This version is currently live on the test/development server.
Comment 4 Matthew Casperson 2014-01-27 23:59:46 UTC
Did various searches with editedBy and createdBy (using lnewson and the Unknown user), and the results came back as expected. We should have the option to negate these searches (i.e. not created by lnewson).
Comment 5 Lee Newson 2014-01-28 00:14:20 UTC
What would be the use case for the above, as I didn't implement it because I couldn't see why anyone could ever require that information. The other reason, is that it is going to return a lot of topics (depending on the database size and number of users).
Comment 6 Lee Newson 2014-02-12 23:31:36 UTC
<mcasperson> the use case is to find all topics that someone else edited. perhaps an author has let some developers contribute to the guide and needs to find all topics that were edited by someone other than themsleves <mcasperson> as opposed to doing multiple searches against usernames, or having to know all the people who might have contributed <mcasperson> it would almost always be used in conjunction with "topics in spec" or something like that
Comment 7 Lee Newson 2014-02-13 07:01:59 UTC
Added the ability to negate the searches using the notEditedBy and notCreatedBy (so that they follow our normal negating variables). This version is currently deployed on the development/test server. Note: We may need to handle null/blank usernames differently.
Comment 8 Lee Newson 2014-02-13 07:03:17 UTC
Additional Note: I've removed the fields from the UI as at the moment they are more than likely going to confuse users until Auth is implemented.
Comment 9 Matthew Casperson 2014-02-13 20:37:17 UTC
Removing the target release flag until this bug can be completed.