No.

I'm not able to reproduce this at HEAD. Are you sure your install is up to date? We expected D14063 to resolve this. If this still reproduces at HEAD, can you give us a better idea of OS/Browser for testing?

We've removed the dot rules from the upstream for security reasons (see T9408) so this is no longer relevant, although it is a concern we might want to address in T4190.

See:

I think we'd likely want to pursue T8646 first and see if that resolves this on its own.

Can you suggest the best way to achieve this?

I remember we had this implemented before, but can not find task why it was removed.

You listed T7783 twice above btw. Was one of those instances supposed to be a different task?

We can look at this as part of the next Phriction iteration, although other changes likely impact the eventual design here.

I don't anticipate implementing these in the upstream. Remarkup is extensible enough that these could be implemented as extensions.

This is a fairly huge amount of complexity for a very niche use case, which makes me hesitant to pursue it in the upstream. I expect the number of installs which would use this feature is on the order of 1, and that it essentially amounts to custom development.

Yeah, I think that's probably the cleanest way to approach this today. That mostly works around the management mess, too.

So the current solution would be: Create a project #board_members, #board_page_editors. Set /board/ view policy to #board_members, edit policy to #board_page_editors, and set up Global Herald rule to add #board_members as subscribers to any page with /board/ in the path?

The described behavior is working as expected, I think.

Specifically, subscribers should have no affect on your ability to create a page, only policies.

In T9371#135913, @jpetso wrote:

@chad, I thought about that too, but this rule only comes into play after the page has been created. Since the view/edit permissions are inherited from the parent page, which has "Subscribers" access in this case, the form complains because without filled-in subscriber list, I "would no longer be able to view/edit the object". The form doesn't know about the Herald rule that makes this possible afterwards.

@epriestley, I agree that in many situations you might not want to auto-subscribe to sub-pages. However, I'm not certain that having "Subscribers" appear on every sub-page is a bad thing - it allows customization if the inherited default is inappropriate for a given page.

That sounds like a separate bug.

@chad, I thought about that too, but this rule only comes into play after the page has been created. Since the view/edit permissions are inherited from the parent page, which has "Subscribers" access in this case, the form complains because without filled-in subscriber list, I "would no longer be able to view/edit the object". The form doesn't know about the Herald rule that makes this possible afterwards.

I think changing the proposed behavior (making subscribers inherited in some form) is possibly reasonable, in that this is probably a common desire, although it seems like users might also reasonably want to subscribe to /x/ without subscribing to /x/*. We could let you "subscribe (this page only)" vs "subscribe (this page and all sub-pages)" but Subscriptions would need to expand substantially to accommodate that and there are no other use cases in other applications that I can think of (except sort-of Projects).

Pretty sure you can accomplish this with a Herald rule:

Possibly related, Edit Notes also don't show up in the Feed. At least for wiki page changes, they would make a lot of sense there. Please ignore this comment if it's not the same (or a similar) underlying technical issue.

@chad: Thanks for the hints! I had forgotten about the other tasks and they didn't turn up for my search terms.

I consider CC'ing a lightweight first-step towards / alternative to reviews. Thus marking this as a duplicate of T4099.

Comment from T9292: I assumed I could @mention them in the Edit Notes and thus trigger a notification and subscription, which would allow me to point them directly to the changes I made and in addition leave them some information why they receive the notification and what I expect from them. Instead @mentions in the Edit Notes have no effect on the subscriptions/notifications.

T4099 is CC'ing users on Phriction changes, T3353 is making changes require review.

Since I recently had to write/update some long phriction docs - section editing would help me greatly!

The issue is that moving a wiki page leaves around a redirect, which other users can still stumple upon, which is bad from a privacy perspective (since the old content can still be restored from the history). Sadly on our installation some very generic names were choosen, which also collide with new project names.

It sounds like T6004 would obsolete this.

Thanks for the hints and ideas.

I don't think macros are necessarily a bad idea or anything, and they'd be an OK fix here, they just seem potentially really complicated and involved and like they're only-an-ok-fix for a handful of not-too-important issues.

The primary use case I see for {!bigproject/presentations/pitch.ppt} or {!design/mocks/notifications.pdf} is non-version-controlled resources which are potentially shared between users and updated a lot of times. But basically the same value as Drive or Dropbox: sharing files with familiar filesystem semantics so you can go look in a folder and see stuff with sensible names and non-technical users have a reasonable shot at figuring it out, too.

Well I've made a mess of this task.

I suppose an example from the original ticket was:

Even setting aside the intentional "Yes" -> "No" template edit, subtle changes to macro text over time could render it meaningless/confusing on old tasks.

I don't want to solve it anytime soon (and don't actually understand it, see bottom).

How do you want to solve @devurandom's use case then?

Even setting aside the intentional "Yes" -> "No" template edit, subtle changes to macro text over time could render it meaningless/confusing on old tasks.

So the idea is that you can either invoke a snippet as a macro, like:

If this should be two separate tasks, that's fine, I assumed we could just build one thing.

Ah, sorry, no I'm not suggesting when used as a template that it updates, only when used as a macro. The "reusable remarkup" seemed to fall into two use cases, but could be built into one application.

Like, there's no useful {{changelog}} macro I can define, since tons of the internal text is different from page to page.

Well, what would the changelog one look like? If it looks like this:

My thought was "here is a block of Remarkup I want to re-use occasionally", that that ends up being either applied as a rough template when creating something or inline rendering the output when used as a macro. Or is this really two systems?

I can create a "weekly_changelog" template which I use in Phriction to quickly apply the common markup I use when building a new Changelog page.

There are two things that come to mind.

Please don't get me wrong. I am doing my best to provide as much helpful feedback as possible, so the product becomes most useful and easy to use in the end.

I can already imagine the faces, when I tell someone who wants to "update" his file that is linked in several locations, he should have created a macro and used that right from the start...