Having some issues while trying several times to set up naming_series and autoname in a DocType

ayito · December 3, 2025, 1:11pm

Hi all
I tell you what happened to me so you may be able to replicate and work something out of it. There are several issues to comment, I’ll try to explain my best what I did (I’m newbie, so take this with a grain of salt)

So, I installed latest development branch and updated as of 03/12//2025 and it’s working. I’m also following Frappe Framework App Development Bootcamp - Day 2 (Dubai, 2024), but trying a bit of new things, this is my second time following such tutorial, doing things in Spanish, my mother language.

So I try to set up a field several times in frappe desk Build DocType, getting frustrated and deleting and doing it all over again, trying to get “autoname”: “naming_series:” the right way, after several tries, 1st try was “fieldtype”: “Link” then deleted it and again the 2nd try also “fieldtype”: “Link” and the 3rd try I configure it as “fieldtype”: “Select”, when I go to the editor I got to read the json and found the field like this:
{
“default”: “1lvtj3rpd4”,
“fieldname”: “naming_series”,
“fieldtype”: “Select”,
“hidden”: 1,
“label”: “N\u00famero de Solicitud”,
“link_filters”: “[[“Document Naming Rule”,“name”,“=”,“1lvtj3rpd4”]]”,
“options”: “1lvtj3rpd4”,
“read_only”: 1,
“reqd”: 1
}

So I can have “autoname”: “naming_series:”. This is good, the problem, I guess is that I didn’t get it right the first time, in fact, I tried to set up for 3 times this to work, creating Document Naming Rules each time and assigning them to my field, first I triead to set it up as “fieldtype”: “Link”, it didn’t work the way I expected, I got frustrated and deleted the Document Naming Rule and created new ones, thinking the problem was there. Then I tried the one it’s copied above with “fieldtype”: “Select”. But I got in the json the “link_filters”: “[[“Document Naming Rule”,“name”,“=”,“1lvtj3rpd4”]]”, and I think this doesn’t make sense for a fieldtype: “Select”.

So after reading the docs, asking serveral ai’s, etc… finally I think I got a clue:

In the mariadb console, I describe the database table of the doctype with:

MariaDB [_a27fa9b18cffdd35]> DESC tabSolicitud de reserva;

The Field referencia, was one of my tries that I deleted (I didn’t named it naming_series, but referencia, my bad!), but remained in the table, when I try to create a new “Solicitud de reserva” in the front end, the first time works as I would expect, creating the record with “ID P-2025-12-0003”, but the second time it throws an error “referencia debe ser único” (“referencia has to be unique”), I deleted this field in the front end and I couldn’t understand what was happening at first → got frustrated!, (it was still in the table with Key UNI).

Also on one of my tries I did name the field “naming_series”, didn’t work, deleted it and on the latest try I also created the Field “naming_series” since everything points that it’s the name it has to be. But the nagging point here is that I couldn’t get read of the default 73f33ve6g4 no matter how many things I tried, deleting the cache with bench --site irfan.cabs clear-cache or bench --site irfan.cabs clear-website-cache, also trying a different browser, just to make sure it was not a browser cache thing. Nothing seems to work. This code 73f33ve6g4 belonged to a previous Document Naming Rule that was also deleted, It was nowhere to be found when I searched the database with SELECT in different tables, like:

MariaDB [_a27fa9b18cffdd35]> SELECT * FROM tabDocument Naming Rule WHERE name = ‘73f33ve6g4’;

Makes sense since I’ve deleted that Document Naming Rule.

So I deleted again the field (in frappe desk Build DocType) and also made sure that those columns where dropped from the table:
MariaDB [_a27fa9b18cffdd35]> ALTER TABLE tabSolicitud de reserva DROP COLUMN naming_series;
MariaDB [_a27fa9b18cffdd35]> ALTER TABLE tabSolicitud de reserva DROP COLUMN referencia;

deleting the field while working in the browser in frappe desk Build DocType is just not enough.

Now there is no “referencia” nor “naming_series” in the json file of the doctype, neither it is in table DESC. I think it is clean now and I can create the field again with nothing there from past tries to fear.

Now in the json file I get:
…
“autoname”: “naming_series:”
…

…

{
“default”: “1lvtj3rpd4”,
“fieldname”: “naming_series”,
“fieldtype”: “Select”,
“hidden”: 1,
“label”: "C\u00f3digo ",
“options”: “1lvtj3rpd4”,
“read_only”: 1,
“reqd”: 1
}
…

But I still get in the DESC of the table this:

…

The nagging reference to the deleted Document naming rule 73f33ve6g4, while it should be the latest and new created Document naming rule 1lvtj3rpd4.

Then I executed this code in mariadb:

MariaDB [_a27fa9b18cffdd35]> ALTER TABLE tabSolicitud de reserva
→ ALTER COLUMN naming_series DROP DEFAULT;
Query OK, 0 rows affected (0.020 sec)
Records: 0 Duplicates: 0 Warnings: 0

MariaDB [_a27fa9b18cffdd35]> UPDATE tabSolicitud de reserva SET naming_series = NULL WHERE naming_series = ‘73f33ve6g4’;
Query OK, 0 rows affected (0.001 sec)
Rows matched: 0 Changed: 0 Warnings: 0

MariaDB [_a27fa9b18cffdd35]> DESC tabSolicitud de reserva;

And finally got:

went to the front end, check the naming_series field and in options and in default was the right code 1lvtj3rpd4, make a change in the label text just to notice the front end of the changes and saved it.

went back to mariadb console and there it was!

the 73f33ve6g4 that I can’t get rid off.

So, I just don’t know what is going on. Time for a bit of brute force I guess.

(frappe-env) ubuntu@frappe-dev:~/frappe-bench$ mysqldump -u root -p _a27fa9b18cffdd35 tabSolicitud\ de\ reserva > solicitud_reserva_backup.sql

and modified the line so it reads with the default I want to get:

naming_series varchar(140) DEFAULT ‘1lvtj3rpd4’

Here’s the full sql:

DROP TABLE IF EXISTS tabSolicitud de reserva;
/*!40101 SET @saved_cs_client = @@character_set_client /;
/!40101 SET character_set_client = utf8mb4 /;
CREATE TABLE tabSolicitud de reserva (
name varchar(140) NOT NULL,
creation datetime(6) DEFAULT NULL,
modified datetime(6) DEFAULT NULL,
modified_by varchar(140) DEFAULT NULL,
owner varchar(140) DEFAULT NULL,
docstatus tinyint(4) NOT NULL DEFAULT 0,
idx int(11) NOT NULL DEFAULT 0,
_user_tags text DEFAULT NULL,
_comments text DEFAULT NULL,
_assign text DEFAULT NULL,
_liked_by text DEFAULT NULL,
nombre_cliente varchar(140) DEFAULT NULL,
telefono_contacto varchar(140) DEFAULT NULL,
fecha_salida datetime(6) DEFAULT NULL,
estado varchar(140) DEFAULT NULL,
direccion_inicio text DEFAULT NULL,
vehiculo varchar(140) DEFAULT NULL,
naming_series varchar(140) DEFAULT ‘1lvtj3rpd4’,
PRIMARY KEY (name),
KEY creation (creation)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC;
/!40101 SET character_set_client = @saved_cs_client */;

and in mariadb console:

MariaDB [_a27fa9b18cffdd35]> DROP TABLE tabSolicitud de reserva;

Then I import the modified sql with:

(frappe-env) ubuntu@frappe-dev:~/frappe-bench$ mysql -u root -p _a27fa9b18cffdd35 < solicitud_reserva_backup.sql

and finally in mariadb console I can read:

…
| naming_series | varchar(140) | YES | | 1lvtj3rpd4 | |
±------------------±-------------±-----±----±-----------±------+

This 1lvtj3rpd4 is the reference to the Document naming rule I wanted to use.

Now is working when I add new records I get: P-2025-12-0004, P-2025-12-0005, P-2025-12-0006,…

Brute force solution seemed to have worked, or it hasn’t? I mean, not fully happy with this, because if a I change to a different Document naming rule I might get into trouble again? Also, I’m not good at python or frappe, just learning and I feel I just got this out of being stubborn rather than using skill. I don’t know if I could have solved it in a better way, I guess I could.

So… any feedback will be wellcomed. Hope you can replicate this experience and come out with a better solution or fix.

Thanxs for the hard work in creating frappe!

Yamen_Zakhour · December 3, 2025, 5:28pm

Since you are developing a custom app, you can simply setup Autonaming in the doctype controller. This is much more cleaner.

If you prefer the UI way, create a select field for naming series (no need for a naming rule link field) then create your rules and export them as fixtures to your apps

ayito · December 3, 2025, 6:08pm

Hi,
Yes, I guess I could do that and of course, I may try it in the future. Though I just wanted to point the 2 issues I’ve had. I’ll try to summarize a bit.

I created a field called “referencia” with property “unique”, save the DocType, try it out, doesn’t work the way I wanted when I go and test it creating a new record, so I deleted this field in the DocType and I also deleted the first and only record I was testing. List is empty again with no records. The field gets deleted from the json, but that column is still in the database table and it is marked as:
referencia | varchar(140) | YES | UNI | 73f33ve6g4 | (UNI → Unique)
1. So even if the field is deleted, when I try other options, the firs record gets stored, but when I try to insert a second record it throws an error stating “referencia has to be unique” (or similar to this, I’m translating as I write from what I remember the Spanish sentence was). You get the point.
2. Conclusion: it seems when creating a DocType, if you create a record with Unique property set, it means it has to be unique, If you try and test creating a few records, then delete this field, it remains in the database table and somehow it was still being validated even if it wasn’t suppose to be there in the form anymore since being deleted. So, is this a bug? a feature? is it documented somewhere? I don’t know. Please someone put some light on this.
Second issue was that when trying to set up a naming_series field it has to be named “naming_series” in order to work ( don’t try referencia or any other because it doesn’t). The problem is similar than in number 1. I tried it, wasn’t happy about it, deleted the field but it remained in the database like this:

| naming_series | varchar(140) | YES | | 73f33ve6g4 | |

Not UNI set, but with default of 73f33ve6g4, but this default correspond to a specific Document naming rule that I also got rid off (deleted it) and didn’t exist anymore. And what is worse, couldn’t change this default value.
When I realised that I have to create the field with the name “naming_series” since the field was already a column in the table belonging to the DocType it got this value, and couldn’t change it.
I solved the issue number 1 by dropping the column “referencia” from the table.
I solved issue number 2 by exporting the table in a sql backup, changing the value of default for the value I wanted to be there “1lvtj3rpd4”, dropping the table and restoring the backup with the correct value.

So, I can and will try different methods to achieve this, I get the point frappe framework try to do things easy for the user and the developer and give my props to that and thanks to all the team involved. Also I’m trying the developer branch from github, so issues may happen. I don’t know if I shall just mentioned here or raise a bug, maybe is not a bug, I don’t know. But for me it was quite confusing and frustrating. Also I haven’t tried to set up a new “Document naming rule” and tried to change it or give it as an option, since the field is a select, I guess it could be there, but as of now it is also a hidden field, so I’ll have to take a look at that scenario more carefully and find out how to set it up, because a customer user is on thing but if the user is a team member, maybe he gets to choose which naming series to use for the new record and in this case the select shall have more options, be visible and these options should make sense for the user, not just codes like: 1lvtj3rpd4, 73f33ve6g4…

Yeah, thanks for your input!

Yamen_Zakhour · December 3, 2025, 6:31pm

Did you try bench migrate after those schema changes? Also make sure developer mode is on.

ayito · December 3, 2025, 6:54pm

Yes, I tried bench migrate, as I was following the youtube tutorial the site is also called irfan.cabs

I did:
- bench --site irfan.cabs migrate
Also:
- bench update --reset (I think it does a migrate in the process), I do this to try the latest code.
In point number one, I did set up the default value of “referencia” to 1lvtj3rpd4, so my guess is that since the field wasn’t there anymore and even if it was deleted for the doctype, it didn’t go well with validation after one record is inserted, because it always got this default value and it was marked as unique. But anyway, it was supposed to be deleted.
I tried many things I might have lost track of all, This is why I mentioned I created the field, link it to the Document naming rule, also to autoname, test introducing the new records, delete the whole thing (fields, configuration, Document naming rules… even the entire Doctype once and go over it again…) it was a mess. Then I went again and again and finally what worked was dropping that “referencia” column and also hard replacing by backing up the table, modify it and restore it with different default value for the “naming_series” field. I wanted to share it in the forums because there has to be a better way.

Yamen_Zakhour · December 3, 2025, 7:09pm

Never encountered this issue, im not sure. But good that it is working right now. Goodluck

ayito · December 3, 2025, 7:22pm

Thanks, it was weird to me.
I mean, it makes sense that once a field is deleted it shouldn’t run any validation on it while inserting new records (the “referencia” case).
Also, in the case of the “naming_series” field, once the field type is changed the json should go accordingly and also the database.
So, maybe is a non issue after all and it’s just my installation. Anyway, hope this thread helps anybody, for me it has been a learning experience.
Best regards!