Email notifications still going out even when WATCHERs removed

[Chris P.]

Little bit of a problem here as I am trying to update 100s of pages via the  Confluence Cloud REST API.

This was never a problem before, until I added in deleting and / or adding attachments to pages.

https://developer.atlassian.com/cloud/confluence/rest/api-group-content---attachments/#api-api-content-id-child-attachment-put 

Now that we do batch updates that include attachments, all of our "SPACE" watchers as well as our individual "Page" watchers get an email that something has been updated.

I thought I have found the solution by removing watchers (for both SPACE and PAGE), making the edits, and then adding them back in.

https://community.atlassian.com/t5/Confluence-questions/Prevent-notifications-when-using-REST-API/qaq-p/948058 

However, even removing both sets of watchers (again via the API):

Remove content watcher 

Remove space watch 

...  users are STILL getting an email notification :(

I tried playing with the timing, thinking that Atlassian may have a update window, where "watcher" flags only get updated every " X " about of minutes, but that did not help either.

I tried removing watchers, and waiting 1, 3, 5, even 10 minutes before making edits, but notifications still came through.

For example:

• 20:01   >   Disabled Watchers 
• 20:06   >   Edit pages 
• 20:11   >   Re-enabled watchers 
• 20:25   >   Received email in user imbox 

[Alex Yasurek]

What about using an include instead? They still may be able to edit the page that is being included if they have rights to the space its coming from but at least they won't be able to on the page you are including it on. 

[Jonathan Simonoff]

I was thinking that. He could restrict editing on the included page, too.

[Davin Studer]

Include is the way to go. Just make sure they don't have perms to edit the included page.

[Kirstin Seidel-Gebert]

Users would be able to remove the include, though.

[Alex Yasurek]

Yes that is true. This would also require some training letting them know not to remove that. If a user has edit rights though there really is no way to stop them from doing that.

[Jonathan Simonoff]

How about this arrangement: You have three pages: one has the content they can change, one has the content they can't change, and the third shows both of them via includes. You then restrict the latter two, and allow them to edit only the first one -- they can't remove the includes (since the page with the includes is restrcited) and they can't edit the restricted page, but they can edit the unrestricted page.

[Dan_Nelson]

Am I missing something with this `include` proposal?  If a page was authored with an `include` directive to a resource that is restricted, any viewers of said page WITHOUT permission to the included content would receive this UGLY and UNFORTUNATE message:

Unable to render {include} The included page could not be found.

That's in no way acceptable for our team's use case(s).  In addition, this include error message does not look professional as the page will appear broken to users.

[Kirstin Seidel-Gebert]

This would only be the case, if users don't have viewing permission, Dan. Just restrict editing, not viewing.

[Timothy]

Nope. You are looking for this (https://jira.atlassian.com/browse/CONF-5913).