Bug 809286 - RFE: Add kerberos id of user who created a topic as a search field.
RFE: Add kerberos id of user who created a topic as a search field.
Product: PressGang CCMS
Classification: Community
Component: Web-UI (Show other bugs)
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: Lee Newson
Depends On: 731902
  Show dependency treegraph
Reported: 2012-04-02 20:38 EDT by Tim Hildred
Modified: 2014-08-04 18:29 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tim Hildred 2012-04-02 20:38:43 EDT
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-02 20:40:25 EDT
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-09 23:43:55 EDT
This should be captured by envers when a topic is created or edited.
Comment 3 Lee Newson 2014-01-14 21:50:12 EST
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:


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 18:59:46 EST
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-27 19:14:20 EST
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 18:31:36 EST
<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 02:01:59 EST
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 02:03:17 EST
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 15:37:17 EST
Removing the target release flag until this bug can be completed.

Note You need to log in before you can comment on or make changes to this bug.