Newspaper: Interesting Problem

[Harvey]

I just realized that one of my customizations is short circuiting a crucial Nabble feature.

Hugo has designed an awesome feature for our Magazine (Newspaper) that allows us to publish our features and keep them private so we can tweak them many times before they are viewed. It essentially a private "forum" with some cool bells and whistles. We then move the piece out and put it in full view when it's ready. (It's not unusual for us to spend 10-20 hours working on a single article.)

But I just realized that the defeats the "subscribe" function. People who've subscribed to new features never get the subscriber email because the piece was first published privately.

Any way around this?

[Hugo <Nabble>]

You are right. I will have to think a little bit more about this. Maybe we should change the move feature so that it can notify subscribers when the topic is moved to the public section. I will take a look and get back to you soon.

[Harvey]

Very cool. Thanks.

On Sat, Jan 21, 2012 at 8:36 PM, Hugo <Nabble> [via Nabble Support] <[hidden email]> wrote:

You are right. I will have to think a little bit more about this. Maybe we should change the move feature so that it can notify subscribers when the topic is moved to the public section. I will take a look and get back to you soon.

Official Nabble Administrator - we never ask for passwords.

---

If you reply to this email, your message will be added to the discussion below:

http://nabble-support.1.n2.nabble.com/Newspaper-Interesting-Problem-tp7210295p7212252.html

To unsubscribe from Newspaper: Interesting Problem, click here.
NAML

--
"Like" us on Facebook: www.facebook.com/NYSkiBlog
Follow us on Twitter: http://twitter.com/nyskiblog
----------
Harvey Road: www.NYSkiBlog.com
NY Ski Forum: forum.NYSkiBlog.com
NY Ski Magazine: mag.NYSkiBlog.com

[Pedro]

Hi,

Harvey, it is now possible to fix the problem you described. The idea is to notify the subscribers when you move topics from the private subapp to the public area of your magazine.

To do this, see the code below:

<override_macro name="save_parent_changes">
	<n.edit_page_node.>
	<!-- If the URL is empty, we use the current app -->
	<n.if.is_empty.trim.parent_url_field.value>
		<then.parent_url_field.set_value value="[n.page_node.get_app_node.url/]"/>
	</n.if.is_empty.trim.parent_url_field.value>        
	<!-- If same site, just move. Otherwise, export it. --> 
	<n.if.url_belongs_to_site url="[n.parent_url_field.value/]">
		<then>
			<n.set_var. name="was_private"><n.edited_node.is_private/></n.set_var.>
			<n.set_parent_url parent_url="[n.parent_url_field.value/]" />                
			<n.save_node/>                
			<n.if.both condition1="[n.var name='was_private'/]" condition2="n.not.edited_node.is_private/]">                  
				<then.edited_node.notify_subscribers/>
			</n.if.both>
		</then>
		<else>
			<!-- Hardcoded link until ExportConfirmation is templated -->
			<n.set_var. name='url'>/catalog/ExportConfirmation.jtp?node=<n.page_node.id/>&url=<n.parent_url_field.value/>
			</n.set_var.>
			<n.redirect_to.var name='url'/>
		</else>
	</n.edit_page_node.>
	<!-- Start tweak -->
	<n.if.visitor.is_site_admin>
		<then.redirect_to.page_node.change_topic_subject_path/>
		<else.redirect_to.page_node.url/>
	</n.if.visitor.is_site_admin>
	<!-- End tweak --> 
</override_macro> 

You should change the "save_parent_changes" macro like shown above. The lines I've added are 10, 13 , 14 and 15.

[Harvey]

Sorry I'm not sure I understand.  What does save parent changes do?

There is already an override macro in save_parent_changes?

Do I end up with two overrides in there?  Can I just add the lines?

Or... can you do it for me?  You've already done the hard part.

[Hugo <Nabble>]

I've made the changes for you (all you would have to do is add lines 10, 13 , 14 and 15 to the default macro code). From now on, subscribers will be notified whenever you move a topic from the "Future Issues" area to the public area.

[Harvey]

So it is possible to edit an existing override without adding a third one?

I had thought this was possible at one point but either I've forgotten how or I was imagining it.

Is there a technical reason why I should add the additional lines?

[Hugo <Nabble>]

Harvey44 wrote

So it is possible to edit an existing override without adding a third one?

Yes. In your case, there was no override for that macro. I added one and I can edit it without adding a third override.

Harvey44 wrote

Is there a technical reason why I should add the additional lines?

The additional lines represent the logic to notify subscribers when a post is moved from a private to a public area. The default macro doesn't notify subscribers when a topic is moved (only when a topic is created). So this is why we had to tweak that code to solve your problem.

[Harvey]

There are currently three macros (1 macro and two overrides?) in save_parent.

Is that correct? Could it be done with two?

I'm not comfortable making this change. Is this something you could do for me?

[Pedro]

Harvey,

We've made the changes for you. Now you will only see two macros. Please take a look and let us know if you see issues.
Subscribers should be notified when you move topics to the public area.

[Harvey]

Thank you very much. Sorry to be chicken on this one.

Questions:

Do the extra macros create bulk or slow the system down?  If a macro had 100 overrides would it matter?

Also why do some macros allow editing and others require a new override macro?

On Wed, Feb 1, 2012 at 11:14 PM, Pedro <Nabble> [via Nabble Support] <[hidden email]> wrote:

Harvey,

We've made the changes for you. Now you will only see two macros. Please take a look and let us know if you see issues.
Subscribers should be notified when you move topics to the public area.

---

If you reply to this email, your message will be added to the discussion below:

http://nabble-support.1.n2.nabble.com/Newspaper-Interesting-Problem-tp7210295p7245703.html

To unsubscribe from Newspaper: Interesting Problem, click here.
NAML

--
"Like" us on Facebook: www.facebook.com/NYSkiBlog
Follow us on Twitter: http://twitter.com/nyskiblog
----------
Harvey Road: www.NYSkiBlog.com
NY Ski Forum: forum.NYSkiBlog.com
NY Ski Magazine: mag.NYSkiBlog.com

[Hugo <Nabble>]

Harvey44 wrote

Do the extra macros create bulk or slow the system down?  If a macro had
100 overrides would it matter?

This shouldn't affect speed. It is only complexity that we want to avoid.

Harvey44 wrote

Also why do some macros allow editing and others require a new override
macro?

Users can't really change the core NAML macros. They can edit/tweak them by creating an override (which can be edited as many times as the user wants). But if users want, they can also create new macros that are not in the NAML core. In those cases, they have full control over those macros (create/edit/delete).

[Harvey]

Hugo <Nabble> wrote

Harvey44 wrote

Do the extra macros create bulk or slow the system down?  If a macro had
100 overrides would it matter?

This shouldn't affect speed. It is only complexity that we want to avoid.

Harvey44 wrote

Also why do some macros allow editing and others require a new override
macro?

Users can't really change the core NAML macros. They can edit/tweak them by creating an override (which can be edited as many times as the user wants). But if users want, they can also create new macros that are not in the NAML core. In those cases, they have full control over those macros (create/edit/delete).

I think it's very smart not to let us edit core NAML macros. :)

I just wondered why some overrides create additional macros and in some I can edit my own work.