Discussion forum for the RedDotPlugin

This plugin has been extracted from the NatSkinPlugin.

-- MichaelDaum - 23 Aug 2005

Wow, yet another Plugin from you Michael! Thanks a bunch

From the doc it is not clear what red dot means. Is it a red dot icon next to the link, or a link represented with a red dotted underline? You could possibly add a screenshot or simulated HTML to clarify that.

-- PeterThoeny - 24 Aug 2005

Oh, it's a link represented as a red dot. I added an example to the docu topic.

-- MichaelDaum - 24 Aug 2005

Its not entirely clear to me what problem this plugin solves.

-- ArthurClemens - 24 Aug 2005

If you've got a frontpage made up of several INCLUDEs then every fragment can have a red dot that allows to edit it quickly. A user will only see those red dots for which he has write access. Red dots are less disturbing the layout than clumsy "edit me" hrefs. Same with WebLeftBars that are made up of differen sections (site section, web section, my section, whatever section). Use your imagination for more examples or possible extensions of this concept.

(btw. take a look at http://reddot.com)

-- MichaelDaum - 24 Aug 2005

Ah, so a red dot point to an included topic, and provides a direct link to edit it, if the user has edit rights to that topic.

Perhaps the dot's <title> tag can show the included topic name/location, revision and author?

-- ArthurClemens - 25 Aug 2005

BTW the demo topic does not exist.

-- ArthurClemens - 25 Aug 2005

Oh, I didn't install the RDP on nats-www yet. It is still in the NatSkinPlugin there. Bah.

When hovering over the red dot link an "Edit web.topic" is already poping up.

But there's another very useful extension of this stuff: redirect back to the topic the red dot was on. So I will be able to edit a fragment from my frontpage and after it is done I will get back to the frontpage and not stay on the fragment topic. This can already be simulated with the RedirectPlugin by putting a REDIRECT to the frontpage. But if one fragment is used in different places (like in a blogging application) a static REDIRECT won't satisfy. You'd want to get back to where you started.

-- MichaelDaum - 25 Aug 2005

wow, thanks Michael, I look forward to implementing this. Thanks for sharing!

-- MattWilkie - 25 Aug 2005

Implemented the jump-back-to-origin feature in v1.01.

-- MichaelDaum - 16 Sep 2005

New release v1.27, svn r7002: do not overwrite system oopses

-- MichaelDaum - 12 Oct 2005

New release v1.29: fixes deprecation warnings on a dakar installation

-- MichaelDaum - 01 Dec 2005

Maybe what I want is related: I just finished my first large technical specification written entirely in wiki. For the non-wiki literate, I need to prepare a PDF. These users are confused by all of the wiki question marks after dangling, not yet written, pages.

I am looking for a plugin or something else that converts those question marks into something innocuous - such as a little dot. Something that will confuse my non-wiki readers less.

-- AndyGlew - 19 May 2006

I think you don't need a plugin. There is a hidden/non-documented feature in twiki4:

• Set NEWTOPICLINKSYMBOL = .
• Set NEWTOPICBGCOLOR = white
• Set NEWTOPICFONTCOLOR = red

Let's see how FooBarBaz now looks.

<style type="text/css">
.twikiNewLink,
.twikiNewLink font,
.twikiNewLink a,
.twikiNewLink a sup {
  text-decoration:none;
  border:0px;
  background:white;
}
.twikiNewLink a b {
   color:red;
}
</style>

-- MichaelDaum - 19 May 2006

Not sure if this is a bug. I've got Dakar (+ NatSkin + BlogUp) on web hosting, with the bin scripts in the TWiki root directory. This means that my ScriptUrlPath is just /, so a typical page is http://host.domain.name/view/TWiki/BlahBlah. In NatSkin, the Red Dots render links as http://edit/TWiki/BlahBlah (which of course fail) instead of http://host.domain.name/edit/TWiki/BlahBlah.

I also found that Nat's "Create your personalized sidebar" link had the same problem, but I replaced SCRIPTURLPATH with SCRIPTURL in the included topic and that fixed it.

What's the best solution for the Red Dots?

-- MarcusLeonard - 26 Sep 2006

Marcus, can you try this patch please: RedDotPlugin_pm.patch. Thanks.

-- MichaelDaum - 26 Sep 2006

Okay, ran patch -i RedDotPlugin_pm.patch -p0 and got

patching file lib/TWiki/Plugins/RedDotPlugin.pm
Hunk #1 FAILED at 109.
1 out of 1 hunk FAILED -- saving rejects to file lib/TWiki/Plugins/RedDotPlugin.pm.rej

As an alternative to this, if I replace SCRIPTURLPATH with SCRIPTURL in RedDotPlugin.pm, will that solve the red dot linking problem?

Also: I noticed that blog images weren't working because BLOGIMAGES doesn't seem to be set. I set it in WebPreferences and now it's working.

-- MarcusLeonard - 08 Oct 2006

Anyone seen this error before?

Can't call method "clearSessionValue" on an undefined value at /usr/local/wiki-var/lib//TWiki/Plugins/RedDotPlugin.pm line 161.

I upgraded to TWiki 4.1 and even with the plugin disabled it would still give the error. Had to remove the file to get it to work.

Update The error was a result of me not having v1.37, instead I had v1.33, it now works.

-- EricHanson - 01 May 2007

Hi there,

For our intranet, we are integrating TWiki Freetown using the RedDotPlugin and a Ldap integration.

RedDotPlugin encounter some problems with authentication and nobody can see the red dot (login value problem) except the "admin" user.

I check that the current method used to identify user and check permission is this one: TWiki::Func::checkAccessPermission

I modified this function to this one used for the "edit" mode:

$hasEditAccess = $session->security->checkAccessPermission('CHANGE', $session->{user}, undef, undef, $thisTopic, $thisWeb );

This change is made in the TWiki/RedDotPlugin.pm at line 173

Let me know if this change can be applied to the current plugin, this would help us for maintenance.

Thanks a lot

Gael

-- GaelCrova - 27 Feb 2008

That's probably related to a report on the LdapContrib package that it can't verify authorization of a WikiUserName to a TWikiGroup made up of LoginNames. While your fix might cure this problem, passing the session user instead of the WikiUserName, it circumvents the Func API facade that is supposed to be used by plugins to access the TWiki core. There is also a related bug in Freetown that checking ACLs using a WikiUserName and using a LoginName don't behave the same.

So...you fixed it but there are deeper problems lurking beyond the surface Stay tuned.

-- MichaelDaum - 27 Feb 2008

I changed the ModificationPolicy of this extension from ContactAuthorFirst to PleaseFeelFreeToModify due to inactivity. Anyone please feel free to work on this extension.

-- PeterThoeny - 2012-12-03