Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 3.2 M1
-
Fix Version/s: None
-
Component/s: Activity stream/Event Stream
-
Labels:None
-
Difficulty:Unknown
-
Similar issues:
XWIKI-6195Section editing fails to edit the correct section under some circumstances XWIKI-5794Activity Stream Still Blank XWIKI-7520Activity Stream performance regression XWIKI-7885Message Stream input is not displayed when editing the Dashboard XWIKI-6558Align nicely activity stream events XWIKI-8773Documents are saved as minor versions when clicking the "Save & Continue" button even if the "Is minor edit" checkbox is cleared XWIKI-8765 When upgrading a wiki, do not display what happened (files edited, etc.) in the Activity Stream XWIKI-6698 Be able to filter Activity Stream from the UI XWIKI-8493Unable to delete a message from the "Activity Stream" on IE8 XWIKI-3728"Exception while parsing HTML" when saving WYSIWYG with some content
Description
To reproduce:
- Create a new page with the following content:
{{groovy}}
if (request.getParameter("confirm") == "1") {
def mydoc = xwiki.getDocument("Sandbox.TestPage1")
mydoc.addAttachment("test1.png", "content1".getBytes())
mydoc.save("test1", true)
}
{{/groovy}}
- Add ?confirm=1 to this page URL to execute its code
- Check the history of Sandbox.TestPage1 and verify that the attachment addition was done as a *minor* edit
- Go to the activity stream and you'll notice that the change is displayed even though it's a minor edit and thus shouldn't be shown by defaut
I see in our code that we have:
#if ("$!aMinor" == 'false') #set ($filterClause = $filterClause + " and not (act.version not like '%.1' and act.type = 'update')") #endWhy do we consider only minor editions for "update" types?
What would be the issue if we use the following instead:
#if ("$!aMinor" == 'false') #set ($filterClause = $filterClause + " and not (act.version not like '%.1')") #end