Tiki Wiki CMS Groupware

I guess that brings problems considering tiki structure, because
permissions are granted to user in tiki-setup.php, before we know what
object user is seeing to know if he/she is owner or not.

Since my efforts to make WYSIWYCA, I realized that we already have too
much rules for permissions, and this make things very hard for having
an sql query that checks permission (and without this, I guess tiki
can't be really safe). So this kind of thing frights me.

Do you have any idea on how to implement this?

cheers
batawata

On 1/30/06, Marc Fargas <telenieko@...> wrote:
> Hey,
> What do you think about a "special" group like the "CREATOR_OWNER" from
> widows ? The idea is for example; you give tiki_p_edit to everybody, and
> then tiki_p_lock to 'CREATOR_OWNER' then, the one who created the page wi=
ll
> be able to lock it. One better example would be tiki_p_create to anyone,
> then tiki_p_edit to CREATOR_OWNER (ala UserPage) but there's no
> tiki_p_create (yet!)
>
> What do you think about such functionality? do you have a better name tha=
n
> CREATOR_OWNER ?
>
> See you,
> Marc Fargas.
>

Josef Drexler wrote:
> 
> Hi,
> 
> I've made a bunch of modifications to tikiwiki 1.9.2 for my own wiki, 
> and was wondering if/how I should submit them for inclusion in tikiwiki.
> 
> This is what I changed:
> 
> - changed character diff to word-based diff, the character diff was
>   creating very silly differences
> - new diff option "inline", like side-by-side but only one column showing
>   additions and removals
> 
> for an example of the above see 
> http://wiki.ttdpatch.net/tiki-pagehistory.php?page=Action0Trains&diff_style=mininlinediff&oldver=45&newver=48&compare=1 
> 
> 
> - changed !/!!/etc headings to produce stable <A NAME="..."> anchors to
>   allow linking to them (using the urlencode form of the header line)
> - changed {maketoc} to use these anchors instead of randomly generated
>   ones
> - allowed explicit ((...)) links to use anchors, such as
>   ((Action0GeneralVariables#Cargo+translation+table+%2809%29|cargo
>   translation table))
> 
> for an example of this see 
> http://wiki.ttdpatch.net/tiki-index.php?page=Action0Cargos
> there is an anchor link under headings "Cargo classes (16)" and "Cargo 
> label (17)"
> 
> - when the wiki option "Open page as structure" is enabled, make the
>   structure header on each page use page=foo instead of page_id=bar
>   for linking the relative pages (for more consistent URLs)
> - in "Last Changes" box, remove useless order number and replace it with
>   age of change
> - changed {toc} to add page description on page, not just link title
> 
> all of these can be seen at e.g. 
> http://wiki.ttdpatch.net/tiki-index.php?page=AdditionalReferences
> 
> I'd be interested to hear which of these might be of interest to the 
> tikiwiki community.
> 

Hi,

You can commit these directly to CVS providing you abide by 3 golden 
rules listed on the URL below.

* [http://tikiwiki.org/3rules]

The diff formatting would be required to be optionally selectable like 
the others currently are.

All we need to know is your SourceForge username and away you go.

Cheers

-- 
Damian Parker
http://www.damosoft.co.uk

Damian Parker wrote:
> 
> You can commit these directly to CVS providing you abide by 3 golden 
> rules listed on the URL below.
> 
> * [http://tikiwiki.org/3rules]
> 
> The diff formatting would be required to be optionally selectable like 
> the others currently are.

Well, the "inline" option is just another diff option, so that should be 
no problem.  In my case it's the default option because I like it better, 
but I can put it below side-by-side as well.  However, changing the 
character based diff to word based diff might need to be an additional 
option somewhere (although I consider the char based diff to be rather 
broken...).  If so, what would be a good place for it?

Also, could making the "#" character in ((...)) links use anchors cause 
any problems?  I don't know if it's a valid character in the page name. 
Since it's a special character in URLs I doubt anyone would use it for 
anything else, though.

> All we need to know is your SourceForge username and away you go.

I'm jdrexler on SourceForge.

-- 
Josef Drexler

Josef Drexler wrote:
> Damian Parker wrote:
> 
>>
>> You can commit these directly to CVS providing you abide by 3 golden 
>> rules listed on the URL below.
>>
>> * [http://tikiwiki.org/3rules]
>>
>> The diff formatting would be required to be optionally selectable like 
>> the others currently are.
> 
> 
> Well, the "inline" option is just another diff option, so that should be 
> no problem.  In my case it's the default option because I like it 
> better, but I can put it below side-by-side as well.  However, changing 
> the character based diff to word based diff might need to be an 
> additional option somewhere (although I consider the char based diff to 
> be rather broken...).  If so, what would be a good place for it?

Admin->Wiki, I think Sylvie already has a option there for diff style.

> Also, could making the "#" character in ((...)) links use anchors cause 
> any problems?  I don't know if it's a valid character in the page name. 
> Since it's a special character in URLs I doubt anyone would use it for 
> anything else, though.
> 

Yes, depending on the syntax in use it can be a valid wikipage 
character. Again make it optional on admin->wiki

>> All we need to know is your SourceForge username and away you go.
> 
> 
> I'm jdrexler on SourceForge.
> 

Consider yourself added.

Welcome aboard the Tiki!

-- 
Damian Parker
http://www.damosoft.co.uk

Josef Drexler wrote:

>
> Hi,
>
> I've made a bunch of modifications to tikiwiki 1.9.2 for my own wiki, 
> and was wondering if/how I should submit them for inclusion in tikiwiki.
>
> This is what I changed:
>
> - changed character diff to word-based diff, the character diff was
>   creating very silly differences


Nice.

> - new diff option "inline", like side-by-side but only one column showing
>   additions and removals
>
> for an example of the above see 
> http://wiki.ttdpatch.net/tiki-pagehistory.php?page=Action0Trains&diff_style=mininlinediff&oldver=45&newver=48&compare=1 
>


more diffs -> good.


>
> - changed !/!!/etc headings to produce stable <A NAME="..."> anchors to
>   allow linking to them (using the urlencode form of the header line)
> - changed {maketoc} to use these anchors instead of randomly generated
>   ones


I have always wondered about these randomly generated anchors. I see no 
use to them. It is annoying because if you change your page headings, 
you need to update the anchors... Can someone give me a good reason why 
we should't switch to this new behavior?


> - allowed explicit ((...)) links to use anchors, such as
>   ((Action0GeneralVariables#Cargo+translation+table+%2809%29|cargo
>   translation table))

I like it.  Is this risky?

In external links, are # allowed?

>
> for an example of this see 
> http://wiki.ttdpatch.net/tiki-index.php?page=Action0Cargos
> there is an anchor link under headings "Cargo classes (16)" and "Cargo 
> label (17)"


Excellent!

>
> - when the wiki option "Open page as structure" is enabled, make the
>   structure header on each page use page=foo instead of page_id=bar
>   for linking the relative pages (for more consistent URLs)

Not sure this is what I think it is. But +1 for more consistant & 
meaningful URLs.

> - in "Last Changes" box, remove useless order number and replace it with
>   age of change

interesting.

> - changed {toc} to add page description on page, not just link title
>
> all of these can be seen at e.g. 
> http://wiki.ttdpatch.net/tiki-index.php?page=AdditionalReferences
>
> I'd be interested to hear which of these might be of interest to the 
> tikiwiki community.
>

Josef: All your changes fit in nicely to make Tiki more user-friendly 
and powerful. Please do contribute all these changes and any others you 
may develop in the future.

BRANCH-1-9 is for bugfixes
HEAD is for new features

However, if you have a minor feature/interface enhancement, which 
doesn't affect the database and you are confident it won't introduce bad 
bugs, please add to BRANCH-1-9 and it will be part of Tiki 1.9.3 

Please join us on #tikiwiki

Best regards,

M ;-)

> -----Original Message-----
> From: tikiwiki-devel-admin@...
> [mailto:tikiwiki-devel-admin@... Behalf Of Josef
> Drexler
> Sent: Sunday, January 29, 2006 4:12 PM
> To: tikiwiki-devel@...
> Subject: Re: [Tikiwiki-devel] Submitting code changes
>
>
> Damian Parker wrote:
> >
> > You can commit these directly to CVS providing you abide by 3 golden
> > rules listed on the URL below.
> >
> > * [http://tikiwiki.org/3rules]
> >
> > The diff formatting would be required to be optionally selectable like
> > the others currently are.
>
> Well, the "inline" option is just another diff option, so that should be
> no problem.  In my case it's the default option because I like it better,
> but I can put it below side-by-side as well.
In admin->wiki, there is already a choice between old style and no style. I
think it will be easy to put your choice there

> However, changing the
> character based diff to word based diff might need to be an additional
> option somewhere (although I consider the char based diff to be rather
> broken...).  If so, what would be a good place for it?
Isn't it another renderer? If it is, it can be easy to change
renderer_character with renderer_word
I think that it was on character basis because when it was developped, it
was to copy mediawiki. It seems that mediawiki now is on a word basis too.
So it is a good move, I think... But as Damian said, tw has a (sometimes
stupid) rule to keep change optional

>
> Also, could making the "#" character in ((...)) links use anchors cause
> any problems?  I don't know if it's a valid character in the page name.
> Since it's a special character in URLs I doubt anyone would use it for
> anything else, though.
As Marc said, I don't know why it is dynamic. For me it is a bug.
I saw you based the anchor name on the heading text. What happens if you
change the heading text

>
> > All we need to know is your SourceForge username and away you go.
>
> I'm jdrexler on SourceForge.
Welcome aboard tw.

sylvie

Sylvie Greverend wrote:
> Josef Drexler wrote:
>>Well, the "inline" option is just another diff option, so that should be
>>no problem.  In my case it's the default option because I like it better,
>>but I can put it below side-by-side as well.
> 
> In admin->wiki, there is already a choice between old style and no style. I
> think it will be easy to put your choice there

Right.

>>However, changing the
>>character based diff to word based diff might need to be an additional
>>option somewhere (although I consider the char based diff to be rather
>>broken...).  If so, what would be a good place for it?
> 
> Isn't it another renderer? If it is, it can be easy to change
> renderer_character with renderer_word
> I think that it was on character basis because when it was developped, it
> was to copy mediawiki. It seems that mediawiki now is on a word basis too.
> So it is a good move, I think... But as Damian said, tw has a (sometimes
> stupid) rule to keep change optional

Well, I didn't think of adding a word renderer in addition to a char 
renderer, so atm in my code it just replaces it.  In principle, having both 
wouldn't be difficult though, so I can make it an option as well.

>>Also, could making the "#" character in ((...)) links use anchors cause
>>any problems?  I don't know if it's a valid character in the page name.
>>Since it's a special character in URLs I doubt anyone would use it for
>>anything else, though.
> 
> As Marc said, I don't know why it is dynamic. For me it is a bug.
> I saw you based the anchor name on the heading text. What happens if you
> change the heading text

Then the anchor changes (along with the {maketoc} links).  If someone wants 
to keep the old anchor in addition to the new one, they'll have to manually 
add one with the ANAME plugin.

There is currently no provision for cases where several headings are the 
same, e.g.
!Chapter 1
!!Summary
!!Text
!Chapter 2
!!Summary
!!Text

Here linking to either of the Summary or Text sections will be unreliable, 
but in such cases, users can always manually add unique anchors as well.  My 
change was mainly to facilitate linking to sections directly without having 
to edit the page to insert anchors, and especially being able to copy&paste 
the link made by {maketoc} without having to read the page source to find 
out what the anchor is actually called.

>>>All we need to know is your SourceForge username and away you go.
>>
>>I'm jdrexler on SourceForge.
> 
> Welcome aboard tw.

Thanks!

-- 
Josef Drexler

On 1/30/06, Sylvie Greverend <sgreverend@...> wrote:
>
> > However, changing the
> > character based diff to word based diff might need to be an additional
> > option somewhere (although I consider the char based diff to be rather
> > broken...).  If so, what would be a good place for it?
> Isn't it another renderer? If it is, it can be easy to change
> renderer_character with renderer_word
> I think that it was on character basis because when it was developped, it
> was to copy mediawiki. It seems that mediawiki now is on a word basis too=
.
> So it is a good move, I think... But as Damian said, tw has a (sometimes
> stupid) rule to keep change optional
>

sometimes stupid enough for not using it, as imo good sense should
always override rules. ok, this is my opinion and I don't want to
flame, but if current diff is broken, this can be considered a bug and
so we don't have to make it optional, right?

> >
> > Also, could making the "#" character in ((...)) links use anchors cause
> > any problems?  I don't know if it's a valid character in the page name.
> > Since it's a special character in URLs I doubt anyone would use it for
> > anything else, though.
> As Marc said, I don't know why it is dynamic. For me it is a bug.
> I saw you based the anchor name on the heading text. What happens if you
> change the heading text

+1 on considering dynamic anchors a bug

>
> >
> > > All we need to know is your SourceForge username and away you go.
> >
> > I'm jdrexler on SourceForge.
> Welcome aboard tw.

yeah, welcome!

batawata

Is public ("Other users can upload images to this gallery:") in image
gallery is supposed to override any other permission.

I suppose that this can be convenient when a gallery can be created by any
user, to have this user decided whether or not he wants it public .. even if
the admin says that no image can be viewed?

Actually, a public gallery with special perm or if not global
tiki_p_view_image_gallery'

What do you think?
thx
sylvie

maybe this could be a shortcut to assign individual permissions to the gall=
ery?

On 1/21/06, Sylvie Greverend <sgreverend@...> wrote:
> Is public ("Other users can upload images to this gallery:") in image
> gallery is supposed to override any other permission.
>
> I suppose that this can be convenient when a gallery can be created by an=
y
> user, to have this user decided whether or not he wants it public .. even=
 if
> the admin says that no image can be viewed?
>
> Actually, a public gallery with special perm or if not global
> tiki_p_view_image_gallery'
>
> What do you think?
> thx
> sylvie
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

On Sat, Jan 21, 2006 at 03:24:50PM -0500, Sylvie Greverend wrote:
> Is public ("Other users can upload images to this gallery:") in image
> gallery is supposed to override any other permission.
> 
> I suppose that this can be convenient when a gallery can be created by any
> user, to have this user decided whether or not he wants it public .. even if
> the admin says that no image can be viewed?
> 
> Actually, a public gallery with special perm or if not global
> tiki_p_view_image_gallery'
> 
> What do you think?
> thx
> sylvie
> 

Dont mess with its current behaviour, it means others can if also
having the correct permission upload to "your" image gallery.

So if you have a photo site, and a global upload image
permission, the user creating the image gallery can choose if its
only him/her to upload or if anyone else can upload.


-- 

Damian Parker
http://www.damosoft.co.uk

le Tue, Jan 17, 2006 at 11:16:56AM -0800 par Robin Lee Powell :
> Is there any way yet to maintain permission settings on groups of
> pages all at once?

- by using categ perms maybe ?


cheers,
mose

On Tue, Jan 17, 2006 at 08:54:43PM +0100, mose wrote:
> le Tue, Jan 17, 2006 at 11:16:56AM -0800 par Robin Lee Powell :
> > Is there any way yet to maintain permission settings on groups
> > of pages all at once?
> 
> - by using categ perms maybe ?

The only perms I see in
http://www.lojban.org/tiki/tiki-categpermissions.php?categId=4 are
tiki_p_view_categories and tiki_p_admin_categories. 

Neither of those can be used to stop people from viewing Wiki pages,
can they?

-Robin

-- 
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/
Reason #237 To Learn Lojban: "Homonyms: Their Grate!"
Proud Supporter of the Singularity Institute - http://singinst.org/

if a page belongs to a category you don't have tiki_p_view_categories,
then you don't have any permission on that page.

but you can't prevent a group to edit a pages in a category but still see t=
hem.

batawata

On 1/17/06, Robin Lee Powell <rlpowell@...> wrote:
> On Tue, Jan 17, 2006 at 08:54:43PM +0100, mose wrote:
> > le Tue, Jan 17, 2006 at 11:16:56AM -0800 par Robin Lee Powell :
> > > Is there any way yet to maintain permission settings on groups
> > > of pages all at once?
> >
> > - by using categ perms maybe ?
>
> The only perms I see in
> http://www.lojban.org/tiki/tiki-categpermissions.php?categId=3D4 are
> tiki_p_view_categories and tiki_p_admin_categories.
>
> Neither of those can be used to stop people from viewing Wiki pages,
> can they?
>
> -Robin
>
> --
> http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/
> Reason #237 To Learn Lojban: "Homonyms: Their Grate!"
> Proud Supporter of the Singularity Institute - http://singinst.org/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

Actually when you edit a template that doesn't have a copy in
templates/styles/your_style, you save it in the default directory templates
It doesn't seem to me very homegenous with what we say..
Do we have to create a directory templates/styles/your_style if doesn't
exist and save the modified file in there?
What do you think?
sylvie

On Wed, Jan 18, 2006 at 10:25:20AM -0200, Luis Henrique Fagundes
wrote:
> if a page belongs to a category you don't have
> tiki_p_view_categories, then you don't have any permission on that
> page.
> 
> but you can't prevent a group to edit a pages in a category but
> still see them.

Yeah, that doesn't help much then.  Thanks, though.

-Robin

-- 
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/
Reason #237 To Learn Lojban: "Homonyms: Their Grate!"
Proud Supporter of the Singularity Institute - http://singinst.org/

I agree that it's not good, we shouldn't be editing global templates.
Saving always in styles/your_style would be better, so we should
create styles/your_style if it doesn't exist.

But I'd prefer some way that templates/ were never touched, so user
can safely upgrade.

batawata

On 1/18/06, Sylvie Greverend <sgreverend@...> wrote:
> Actually when you edit a template that doesn't have a copy in
> templates/styles/your_style, you save it in the default directory templat=
es
> It doesn't seem to me very homegenous with what we say..
> Do we have to create a directory templates/styles/your_style if doesn't
> exist and save the modified file in there?
> What do you think?
> sylvie
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

Luis Henrique Fagundes wrote:
> I agree that it's not good, we shouldn't be editing global templates.
> Saving always in styles/your_style would be better, so we should
> create styles/your_style if it doesn't exist.

Well actually I have usually given template editing permission to the
graphic designers for a site, and no-one else, so that they can change
the look and feel of the site, without having to learn FTP. I want them
to change the global templates, until the site looks right.

-- 
Dr. David R. Newman, Queen's University Belfast, School of
Management and Economics, Belfast BT7 1NN, Northern Ireland (UK)
Tel. +44 28 9097 3643 FAX: +44 28 9097 5156
mailto:d.r.newman@...
http://www.qub.ac.uk/mgt/

On Wed, 2006-01-18 at 19:18 +0000, David R. Newman wrote:
> Luis Henrique Fagundes wrote:
> > I agree that it's not good, we shouldn't be editing global templates.
> > Saving always in styles/your_style would be better, so we should
> > create styles/your_style if it doesn't exist.
> 
> Well actually I have usually given template editing permission to the
> graphic designers for a site, and no-one else, so that they can change
> the look and feel of the site, without having to learn FTP. I want them
> to change the global templates, until the site looks right.
> 

Editing the global templates messes you up big style for upgrading.  It
should be made to create/update in templates/styles/nameoftheme.  

After all, that is why the template override system was made in the
first place :)


-- 

Damian Parker
http://www.damosoft.co.uk