[pmwiki-users] Attachment handling enhancement request

[ThomasP]

My items were meant as rhetoric questions: whatever the situation is now I
just wanted to expose what should be taken into account if one makes
changes or amendments.

For example, regarding reference to arbitrary files I would say it is at
least not very intuitive at the moment if -- given per-group based storage
-- one wants to address a file in another group than MyGroup, and has to
write the markup

Attach:MyOtherGroup.AnyPage/myfile.txt

in the page MyGroup.SomePage. (If I'm right this is also the source of the
problem that Dominique encountered when he wrote:

> in the related group configuration pages. But, I'm now stuck with the
> fact that there isn't any way to refer to attachments from one group
> into another.

So there IS a problem of referencing files arbitrarily, or at least it is
not obvious how to do it.
)

Somehow I think it would be better if the referencing would _reflect_ the
way of storage (per-group or per-page based), which would be much more
understandable to users instead of explaining them why the reference must
have the current special form "group.page/file.ext".

To take this argument to the end, I would propose to have a referencing of
the form "Attach:/MyGroup/MyPage/myfile.txt" (or
Attach:/MyGroup/myfile.txt in the per-group based case) (i.e.: use
slashes) which is both explicit and, practically, would be implementable
along side the current referencing scheme, so no real change takes place,
but an amendment with still an impact of renewal.

Besides there should be a clear and intutive default search path whenever
the file reference is not fully qualified, i.e. Attach:file.txt.

The permission thing is another thing of discussion, better postponed for
the moment in my opinion. (Just one thing: if I remember right I saw the
permission check being done based on the page where the Attach: markup was
_located_, not based on where the _file_ was located. I can be wrong with
this, but if it is like this, it is also a security issue.)

Dom:
I'm not sure I understand what you mean with "side-by-side group". But it
seems I meant something different than you.

I hope I have clarified a bit what was my concern. I think it is worth
thinking quite long about in which way action should be taken with the
whole issue, if it is one.

Thomas

On Tue, March 27, 2007 19:48, Patrick R. Michaud wrote:
> On Tue, Mar 27, 2007 at 07:52:12AM +0200, pmwikidev at sigproc.de wrote:
>> > Couldn't we have $UploadPrefixFmt customization be improved to
>> > something similar to that is available via $PagePathFmt? I'm
>>
>> Yet the basic concerns are still valid:
>>
>> * Can I address any attachment from anywhere in the wiki, no matter
>> whether I choose per group or per page storing?
>
> Yes.  Simply add the name of a page associated with the attachment
> as part of the Attach: link.  A link like Attach:Group.OtherPage/file.txt
> will always return the "file.txt" attachment associated with
> Group.OtherPage.
>
>> * Are the permissions to access the file properly checked, and is this
>> actually possible? (For example, for accessing files in '/$Group' it is
>> not clear which page parameter should be used in a $AuthFunction call,
>> since we access a group not a page. (*))
>
> Attachments in PmWiki are _always_ accessed through individual pages, even
> if the the uploads directory happens to be organized on a per-group or
> sitewide basis.  For per-group or sitewide organizations, it's simply the
> case that the attachments appear to be available to multiple pages.
>
> So, assuming that $EnableDirectDownload is turned off, it is the read
> authorizations on a page that determines the accessibility of any
> attachments associated with that page (or group or site).
>
> I'll be glad to illustrate with examples, if needed.
>
>> * When changing the addressing scheme, all recipes
>> including/manipulating
>> files from the upload dir should be considered being updated as well (at
>> least in long run) to have unity addressing throughout the wiki.
>
> I don't understand quite what is meant by "changing the addressing scheme"
> here.
>
> Pm
>