I'd like to see more wiki links in general, but this one is not implemented.

Having interproject links brings the issues of having 'forbidden' symbols.
E.g. the link to ProjectA wiki entry can look like this:
ProjectA.Wiki.theentry
If we have a project named "ProjectA.A" or even "ProjectA" this will bring some inconsistency.]]
Locally we solved this with \ sequences, like this "ProjectA\.A" in a cross-project wiki entries.
What is your opinion on that?
Before making contribution would like to discuss it...

I thought about the project name and tried to make sense if it was needed. Escaping adds confusion to the content author so it's best to avoid it. Also, the project name is not currently guaranteed unique by the system, so each project either needs a user-assignable unique name, or use the database unique id that already exists...

Ultimately wikis should link to documents, tickets, and more.

To facilitate linking to another project's wiki article, how about the following steps:

1. While editing the wiki article, the user chooses "Link Project Data" next to the "Images" link.

2. In the "Projects" popup, a list of projects the user has access to is displayed... this can be a list box.

3. When the project in the list is selected, a second listbox reveals the Wiki Articles in that project (again if user has access). This could be expanded later so the user chooses a radio button between wiki, tickets, documents, etc.

4. Upon selecting the wiki article, a text input field calculates the link and the user can copy/paste it. The intention is that at some point the editor will allow pasting into the text field, but it hasn't been a priority. See Figure 1.

5. The calculated link should be readable by content authors and might be something as follows (I'm not really set on this, but putting it out there):

Optional text to display

Where "Project" is required, followed by the Project Id in the database, followed by the link type (Wiki, Ticket, Document, etc), followed by the entry, then followed by optional text to display instead of the wiki text.

If the project name should be visible, then maybe have it inserted as well after the project id... The parser will ignore the project name if one is used.

Additional Notes...

1. It would be nice to have a small icon generated next to the link, like external links, so that the user knows they are leaving this project to visit another.

2. When a wiki page is displayed, the current user's project and project access will need to be queried for user-by-user permissions for rendering the page and project links. If the user doesn't have access to the linked article, then the link should be disabled in some way.

3. If Project # is omitted, then Wiki:... and Ticket:... and Document:... could reference the current project for linking to other material in the current project.

4. Not needed here -- but we would like to have a database mapping for the wiki pages references. This would allow for an easy way to figure out parent and children page relationships. This should be kept in mind with the introduction of project linking. Another benefit is that if someone renames a wiki page (when that feature is added), a parser can quickly update all of the page links on-the-fly.

Figure 1: Popup selection...

[ List Box of Projects ] Radio button to choose Wiki/Document/Ticket [ List Box of Articles ]

Text Field For Alternate Link Name: [ Text Field ]

Calculated Link to be copied:
Optional text to display

Let me know what you think!

Hi Matt,

Thanks for your expanded reply.

The problem, I think, really lies with using entities numbers, but not names - projects, files, etc.
Having a lot of projects will make it difficult to operate links by id only.

Including a project name besides the id will make a parser more complex, because entity name may contain special characters.

My suggestion is the usage of escape sequence (e.g. slashes) for service symbols '|].'. I think its no more confusing than usage of numbers but more expressive. For uniqeness the entity id should be added.
So my strong idea is that we should have the name of an entity in the link as addition to the id.

Would like to hear your opinion about the easy way to identify the project(file) with id and name and not have a very complex link parser.

Ok, I see the value of using a named project.

One workaround to both the escaping and the unique database id could be to allow the project to have a user-defined unique project code. This project code would be entered on the project details page and could be ~15 characters, case-insensitive, prohibiting spaces and brackets []. No two projects can have the same code, and the code can be used for reference in a number of areas.

Optional text to display

If the full project name can be avoided that's great, otherwise, yes the full project name needs to be escaped and a unique id is important.

Let me know what you ultimately decide... and if you need me to help out, for example by adding the unique id field, I can turn something around fairly quickly.

Hi,
I'm busy with primary business activities will continue in a couple of days.

Hi Matt,

I propose the following for links.
1. We add a special identifier field for a project. Case insensitive. Symbols used: a-z,".","-","_".
2. Link syntax:
a) for links within project it stay as is alternate_name or article
b) link starting with | is the seamless sequence now, although TE somehow manages it.[[[[
c) link will look like  .
- Empty means the current project. Otherwise is project id field.
- is wiki, documents, tickets, etc.
- is an identifier, for wiki article name, tickets - ticket number, etc.
- self explainative

Note:
For some entities like documents, plans, forum topics, etc. number ids are still need to be used. A special link builder will be a quite time consuming application. But for the start point the lack of this builder will be ok I think.

Mykhaylo,

This looks great and I agree with what you proposed!

As you suggested, this could be split up into segments, of which the first is absolutely required. If #1 gets done, then we can concentrate on the others later...

1. Parser and html renderer for the proposed inter-project links
2. Tie permissions into the renderer so a link isn't displayed if the user doesn't have project permissions (or provide feedback to the user in some way)
3. Provide a GUI for inputting linked entities

What's the next step?

Matt,

Below is the full proposed plan:

1. <Project id> field for a project. Case insensitive. Symbols used: a-z,".","-","_". Appears between "Title" and "Short Description" in 'Start a project' and in View/Modify project details on 'Details' tab.
Also this field shoulb be visible in a project list to make it easy and fast finding the id of a particular project. I guess it should appear at the same line as 'Organisation' but may be at right side.
2. Parser and html renderer for the proposed inter-project links. Inter-project links will have a special icon.
a) update help for wiki
b) make the parser
2.1. Link syntax:
a) for links within project it stay as is alternate_name or article
b) link starting with | is the seamless sequence now, although TE somehow manages it.[[[[
c) link will look like  .
- Empty means the current project. Otherwise is project id field.
- is wiki, documents, tickets, etc.
- is an identifier, for wiki article name, tickets - ticket number, etc.
- self explainative
3. Tie permissions into the renderer. If user has no rights to view the link:
a) first solution to try: link will be just an underlined text with a special forbid icon. May be a tooltip with 'Forbidden text'.
b) subject to discuss: link will have a popup/alert open with error text or something like that
4. GUI link builder.

Each entry in the list may be considered as a milestone for the project. Step 4 is the most time consuming and probably we wont even start it.

You have noted before what step 1 actions may be done fairly quickly. Comment this according to step 1, please.

As we are doing this only when there are some free development resource, don't expect quick solutions from me.

Steps 1-3 are going to be finished this week.