Documents' properties and auto-numbering

babynus wrote: Waooo !
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

- 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... ) 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.

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! )