Bug 809286 - RFE: Add kerberos id of user who created a topic as a search field.
Summary: RFE: Add kerberos id of user who created a topic as a search field.
Alias: None
Product: PressGang CCMS
Classification: Community
Component: Web-UI
Version: 1.x
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: pressgang-ccms-dev
QA Contact:
Depends On: 731902
TreeView+ depends on / blocked
Reported: 2012-04-03 00:38 UTC by Tim Hildred
Modified: 2018-09-21 23:04 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed:

Attachments (Terms of Use)

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:


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.

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