I think this is part of the code you're looking for:
https://github.com/mantisbt/mantisbt/bl ... i.php#L337
Code: Select all
function project_create( $p_name, $p_description, $p_status...
...
$t_query = 'INSERT INTO {project}
( name, status, enabled, view_state, file_path, description, inherit_global )
VALUES
( ' . db_param() . ', ' . db_param() ....
db_query( $t_query, array( $p_name, ...
# return the id of the new project
return db_insert_id( db_get_table( 'project' ) );
So you see, the table ID is
returned by the code that @atrol provided, and the project API is "passive" about how that ID is generated.
If you need to provide your own project ID, you will need to pass the ID into a new overload of the project_create method, and modify the table schema so that it doesn't AUTOINCREMENT. That would not be a good mod.
I recommend creating a separate index/table where the system still returns its own internal ID, but you map your ID as a custom field to the generated project IDs. Many changes will be required to support that but I think it would be a neat enhancement. This system has a sort of inherent fault, which is that it uses random numbers as user-facing identifiers. That's like using a telephone number, name, or other data About a person as a table key - and then we need extra code to change keys throughout the system. The better way is to use completely meaningless unique identifiers for internal purposes, and then to allow the application to associate metadata with whose IDs. Then it's painless to change the metadata, because it's just another data field, not a primary key. As an example, WordPress associates a "slug" with all post types, so that we can refer to pages by name, and slugs can be changed without changing the underlying table record ID. But note that in MantisBT, we don't login with a record key or refer to people as @23, we login with our user ID and refer to people by @name.
Again, the main point here is that MantisBT exposes most of its primary IDs to the UI. To my knowledge there isn't a function like ui_from_id(type,internal_id) which will translate IDs for projects, bugs, users, etc. ... With this function we would need a corresponding id_from_ui(type,external_id) which, for example, will return the internal project ID from the user-facing ID. Doing this would require mass changes everywhere, in all places where an ID is displayed, rather than foo->id we would need to substitute ui_from_id(foo->id). The ID passed into the system from links would still need to be the internal ID.
I haven't looked at the mechanism for creating tags but if that table is also using Integer AUTOINCREMENT I believe there would be elegance to duplicating how tags are used. And I don't recall the feature but I thought we could associate custom names with tickets as well. Maybe that was a plugin. But what I'm suggesting is that there is already a pattern in MantisBT or doing this kind of thing. You might need to just find it and repurpose that pattern for project.
HTH