Waooo ! :woohoo:
What a long request... 😉

I'll try and answer step by step.

- Define a new field "Client's document name" (or could be a more generic field name, such as "alternate doc's name", or something like that, perhaps the field's name even configurable through parameters), so that we can track both (our client's and our own's) doc's numbering (or naming, more accurately) scheme at the same time.

It would be easy to include External Reference in Documents (like existing in other items) => Ticket #1121 recorded

1- Once a document has been internally approved, and is sent to the client, the file name should default to this client doc's name when the customer downloads it (unless it's blank).

It is a bit more complicated.
How woulkd you guess it is a customer, to provide external Ref ?
Moreover, downlod should include version name, how should it be included if external reference is stored at document level ?

2- It may be useful, in order to achieve 1, to create another configurable "client's doc reference", which would be defined on a per-client basis. That way, when you create a project, and define who (client) is it for, you're already defining the (already configured, assuming the client already existed in your database) "client's doc reference" schema. Since, most likely, this new client's reference is going to be a different combination of many of the same fields as in our own's.

this time, it becomes to really be a mess.
Your request tries to define the best of for ECM, and project'Or RIA is just a project management tool...

3- To define a few more parameters for "document referece": client code, folder code (see 4), client's project code (that may or may not be the same as our project code, see 5)

Is it a day dream ?
👿

4- Folders should have a "code" and another "description" field. Being separated, you get the best of both worlds: folder code is useful in order to filter, and use these fields as parameters for references (see 3), and folder description is more human-friendly. Perhaps in the left-sided documents widget (the one inside the accordion) both of them should be displayed.

Defititively not.
Folders are defined to organize documents,not to name them.
Reference could depend on Document type, not on folder where they are placed.
There is a help to define default document type in each folder, but this is not a fixed reference or dependency.

5- (not so doc related) Projects should have a "client code" that may (probably) differ from internal (our) code. Add a new field "client project code" for projects that can be used as a parameter for a new "client document reference" (see 3).

Ticket 1122 recorded

6- Up to now, the auto-numbering function is constrained within docs of the same type (and, of course, the same project). I.e.: when I upload a new doc, Project'OrRIA checks among docs of the same type (and the same project) which is the one with the highest number, and automatically assignes a (+1) number to my new document. It'd be great if that behaviour could be configured: instead of checking proj+type, it could check just proj, or just type, or just folder code, or folder code+type, or even none (some companies define their numbering scheme as an overall consecutive numbering). (see 7)

The numbering format is already a global parameter : "document reference format"

7- (see 6) It would be useful (to improve the auto-numbering feature) if we could define a range of doc numbers for certain project / folder / type.
E.g.: within a certain project, I define sub-folders, that represent different areas (either location areas, or conceptual areas).
For example:
100- Folder 1
200- Folder 2
...
I may want every doc within the project to have a unique number, but perhaps I'd prefer them to have some sort of a prefix that allows a refined search. I.e.:
Docs in folder 100 -> auto-number starting on 10000
Docs in folder 200 -> auto-number starting on 20000

Very difficult to implement as MProject is not mandatory is the format : format may define global numbering whatever the project.

New fields for every folder (or project, or doc type) could be defined such as: "start auto-number" and "end auto-number".
In case they're left blank, Project'OrRIA would just ignore these and only take into account the (see 6) configured constraints for auto-numbering. These auto-number range-limits should be cross-checked, also, with the parameter that defines the number of characters desired for generated auto-numbers.

You mix Folfer and document type (see previous answer).

Waooo ! :woohoo:
What a long request... 😉

I'll try and answer step by step.

Thanks Babynus for your patience and commitment. This might be Project'OrRIA's Nº1 feature!! 😉
Sorry for my delay, though. I'll also try and replicate your answers one by one, but it may take a few days to gather all the data required :unsure:

- Define a new field "Client's document name" (or could be a more generic field name, such as "alternate doc's name", or something like that, perhaps the field's name even configurable through parameters), so that we can track both (our client's and our own's) doc's numbering (or naming, more accurately) scheme at the same time.

It would be easy to include External Reference in Documents (like existing in other items) => Ticket #1121 recorded

Well... It wouldn't hurt, certainly... but I'm not sure it'd be the optimal way.

A little background:
A- Usually we (design companies) are requested to generate documentation for our customers. Since we are, in a way, "doc generators", most design companies already have their own document numbering/naming schema. I'd be caos otherwise. So. it'd be great if we could adapt Project'OrRIA document reference schema to ours, and not the other way around. (of course, it's an "easier said than done" situation 😛 )

B- Most customers (the bigger the company the more often) also have their own document numbering/naming schema. Wich is, of course, different from ours, and different among other clients'. So we tend to track both doc's names (ours and our client's) inside the document itself. I.e.: the document (as an entity) has two different "name" fields: "Contractor's doc name" and "Client's doc name".

C- Of course, it's the client who tells us the name we are supposed to name every doc. But it's a common situation where we start generating docs and don't have "Client's doc name" data yet. So it's imperative that we give our docs a name (with our schema) before it starts being reviewed. It's usual that we start reviewing certain doc with a name, and after a few revisions, we finally get the "Client's doc name" data, so we can switch names. And, in the doc intself (printed, in paper) there's both names printed.

So, I separated the first proposal in different "stages", so as to gradually implement those that are feasible:

MAIN PROPOSAL: if possible, I think "Client's doc name" data should just be a new field among document properties. Perhaps (so as to make it a more general approach) it could be something like "alternate doc name" or similar. But the associated file remains the same. Thus, we don't get in the way of versioning system. It's just one more field, which would be manually entered and updated. And, of course, could be left blank when not needed.

IMPROVEMENT: when I upload a file for the new version of a document, I can name the file whatever I want, and when I (or anyone) downloads the doc, the downloaded file has the document reference + version as it's name. This is an already existing feature.
The requested feature would be for Project'OrRIA to distinguish whether the downloader is a client or a company's user, and "compose" the file name with "doc reference+version" or "client's doc name+version" accordingly.
Then, as you already stated, the hard part would be to make that distinction.

I imagine (but not sure the amount of work involved, so... :silly: ) that a possibility would be to create two new fields (in the picture "is external" and "is client") among "Profiles" properties, that allow Project'OrRIA to make such distinction.
NOTE: I proposed those two fields, because it may be possible that you need to grant access to the portal to someone who is "an outsider", but not a client, in a different way. It may be useful (and defining either one or two extra new field/s may be a similar amount of work) having that distinction.
Something like:

This distinction might be useful for other things as well, not only for this request.
That way, when you define an e.g. "External project management" Profile, you flag it as "is external" and "is client".
When the user requests a download, Project'OrRIA checks those flags, and composes the file name accordingly.
With this first improvement, could be
- If the downloader is an internal user: existing procedure (composed file name: "doc reference" + "version")
- If the downloader is a client: new procedure (composed file name: "client's doc name" + "version"). Of course, if "client's doc name" was left blank, it should default to existing procedure.

NOTE: this would be field Nº2 in the "Client's doc name reference.png" attachment

NICE-TO-HAVE: as an ultimate improvement, Project'OrRIA could be able to manage different "Clients" entities (as in "company" type of client, not "individual person" client) with different "client's document reference" schema, that would be defined on a similar way as "document reference" is now defined, but on a per-client basis.

As you've already stated, though, this nice-to-have (but in any way critical) improvement might involve a lot of work. And Project'OrRIA might need to acquire quite a few features before it's capable of delivering this one.
Besides, this would only be useful once you get to know your client's naming scheme, and you're able to disaggregate it in different property fields. So perhaps, too much work for too little reward. :unsure:

NOTE: this would be field Nº1 in the "Client's doc name reference.png" attachment

OK, so that'd be all, by now, regarding client's doc name.
I hope I've made myself clear (it's not easy to summarize a written explanation like this one, on a foreign language 😉 )

I'll be back soon, when I get toghether so as to discuss the other topics. I'm taking a deep breath, now 😉

Cheers! (and many, many thanks, Babynus! :cheer: )

Hi,

I recorded your (very detailed) request as Ticket #1124

Hi Babynus,

I took a deep breath, and now I'm back 😉

Regarding the auto-numbering function:

3- To define a few more parameters for "document referece": client code, folder code (see 4), client's project code (that may or may not be the same as our project code, see 5)

Is it a day dream ?
👿

Well, I may have been dreaming awake lately... 😛
Anyway, I don't think this is a dream.

Indeed, I don't have a clue about the amount of work necessary to provide such a change in functionality, that's for sure... :unsure: so it's not like I'm demanding anything. :silly:

But, what I do know, is that it would be, not only a nice improvement, but also a really necessary feature.
Most companies have already established their own naming scheme. Probably, many years ago, and have already generated tons of documents with such a schema. It's not realistic to expect them to "swith" to Project'OrRIA fixed scheme.

I believe this proposal pursues the improvement of one of (in my opinion) best features of Project'OrRIA: to let portal admins configure it to suit their needs. It's just one more of those things that usually needs to be tailored.

So, to the point:
In order to be able to suit as most naming schemes as possible, the configurable reference should provide the option to select as many document's property fields as possible.
I'd propose to add, first, the following fields:
- Client's proyect code
- Client code
- Top Project code (the project of which this one is a sub-project of)
- (name)
- (version)
- (number)

NOTE: It would be useful if the fields "name", "version" and "number" could be added as parameters as well, so that you get to choose their position within the concatenated string.

NOTE (2): is common pratice that projects get divided in different "areas" (whether they're geographical or functional). An easy way to represent this in Project'OrRIA would be to create sub-projects for every area. So, including "Top Project code" as a parameter would allow to use "Area codes" in document's names.
All this, along with "Identifiers for auto-numbering", would solve the areas/folders/auto-number situation that I had mentioned previously. Which, by the way, was wrong indeed: folders are nowadays defined portal-wide (right?), and behave as templates for every project.

Example:

Project code= PROJ1
Number= 2
Type code= LD
Name= Test document

If the format for reference number was configured as shown in the picture:

Then the example document's file name would be:
PROJ1-0002-LD-Test document.ext

There's another feature that would be very helpful:

The numbering format is already a global parameter : "document reference format"

What I meant is a little bit different from what numbering format is capable of doing right now. I'll try to explain myself better:

As you can see in the picture, I'd propose two different fields: (1)"format for reference" and (2)"identifiers for auto-numbering" (actually, couldn't find a better name =p)

(1)"format for reference": I removed the word "prefix" as it would be useful to be able to select the order of the parameters (including number and name). These are the ones that define the concatenated string for the file name.
(2)"identifiers for auto-numbering": these would be the parameters chosen so as to manage auto-number process. For example in the picture, you'd use {PROJ}, {TYPE}, {NUMBER} and {NAME} so as to generate the file name. BUT, the only field checked to auto-number the doc would be {PROJ}. So, in that case, every doc within that proyect would have a unique number, disregarding all the fields you use generate the file name.
Similarly, if left blank, ALL documents uploaded to Project'OrRIA would get a unique number, no matter what client, project, etc, would it belong to. But the main thing here is that admins would be able to choose such behaviour.

Example:
- CASE 1: "Identifiers for auto-numbering"= {PROY}
You upload 3 docs:

DOC1:
Project code= PROJ1
Type code= LD
Name= Test document

DOC2:
Project code= PROJ1
Type code= HS
Name= Plot 1

DOC3:
Project code= PROJ2
Type code= HS
Name= Plot 2

So, with "format for reference" defined as in the picture, numbers and file names would result:
DOC1: number=1 file name=PROJ1-0001-LD-Test document.ext
DOC2: number=2 file name=PROJ1-0002-HS-Plot 1.ext
DOC3: number=1 file name=PROJ2-0001-HS-Plot 2.ext

When generating the doc's number, it checks the first available number within the project.

- CASE 2: "Identifiers for auto-numbering"=
You upload the same 3 docs:

So, with "format for reference" defined as in the picture, numbers and file names would result:
DOC1: number=1 file name=PROJ1-0001-LD-Test document.ext
DOC2: number=2 file name=PROJ1-0002-HS-Plot 1.ext
DOC3: number=3 file name=PROJ2-0003-HS-Plot 2.ext

When generating the doc's number, it checks the first available number within the whole portal.

That'd be all regarding this. I hope I've made myself clearer this time.

Cheers! And thanks again! :cheer:

By the way:

When checking the online manual, I found a little problem regarding side description text in the "Global Parameters" page:
Online Manual - Global Parameters 1/2
Online Manual - Global Parameters 2/2

Pictures and descriptions are not coincident. Could deduce from context, anyway, so it's not critical, but wanted to point it out, just in case. 😉

Hi
I completed ticket #1124 with your detailed proposale

When checking the online manual, I found a little problem regarding side description text in the "Global Parameters" page:
Online Manual - Global Parameters 1/2
Online Manual - Global Parameters 2/2

Pictures and descriptions are not coincident. Could deduce from context, anyway, so it's not critical, but wanted to point it out, just in case

You're right. 😉
The online version is quite old. :blush:

You'd beeter rely on a cleaner one, for instance the one provided with each deployment : http://track.projectorria.org/manual/manual.php?section=GlobalParameter
(now, description for global parameters have 5 pages) :whistle:

I'll update online version when deployong V3.4. 🙂

Hi
I completed ticket #1124 with your detailed proposale

I wish I could do more than just typing detailed proposals, but I'm afraid php scripting is out of my league by now... :S

Well, to be precise, it might be a looooooooooong "by now" :whistle:

I'll update online version when deployong V3.4. 🙂

Great news! :woohoo: