ในการจัดอบรมการพัฒนา Business Application ด้วย AppSheet ให้กับองค์กรต่าง ๆ ที่ผ่านมา ทาง Datayolk จะมี Session พิเศษของการอบรมที่เปิดโอกาสให้ทางองค์กรเสนอบางฟีเจอร์ที่อยากให้ทางเราสอนเป็นพิเศษในการจัดอบรม ซึ่งเราพบว่าหนึ่งในฟีเจอร์ที่ทางองค์กรร้องขอมากที่สุด ได้แก่การกำหนดสิทธิการใช้งาน ผ่านระบบที่เรียกว่า Permission
สำหรับผู้อ่านที่ยังไม่แน่ใจว่าโปรเจคที่อยากทำ เหมาะแก่การใช้ AppSheet หรือไม่ ? ทางเรามีบทความ รู้จัก AppSheet เครื่องมือสร้างแอปพลิเคชั่นสำหรับองค์กรที่ต้องการ Digital transformation ให้ไปศึกษาเพิ่มเติมต่อด้วย
สนใจเรียน AppSheet กับเรา ?
ไม่ต้องเสียเวลาเรียนรู้ AppSheet ด้วยตัวเอง เพียงแค่เรียนคอร์ส AppSheet Intensive Course ผ่าน Facebook Group กับเรา พร้อมให้คำปรึกษาหลังเรียน
กำหนดสิทธิการใช้งานใน AppSheet เพื่อไม่ให้เกิดแก้ไขข้อมูลโดยไม่ได้ตั้งใจ
ในการทำงานภายในองค์กรแน่นอน ว่าจะมีข้อมูลบางอย่างที่แม้แต่เป็นคนในองค์กร หรือคู่ค้าธุรกิจก็ไม่ควรรู้ เช่นมูลค่าสินค้าที่ขาย ข้อมูลส่วนตัวลูกค้า ข้อมูลทางการเงิน และอื่น ๆ ข้อมูลเหล่านี้ตามปกติจะมีแค่คนบางคนสามารถเข้าถึงได้ เช่นฝ่ายการเงิน ฝ่ายทรัพยากรมนุษย์ หรือฝ่ายบริหารเพื่อความปลอดภัย
พอองค์กรตัดสินใจใช้แอปพลิเคชั่นมาช่วยบริหารจัดการตรงนี้ สิ่งนี้ก็ยังคงเป็นสิ่งที่ขาดไม่ได้ในการรักษาความลับภายในองค์กร ซึ่งในการทำแอปพลิเคชั่น เราเรียกการกำหนดสิทธิการใช้งานในลักษณะนี้ว่า การทำ Permission
แนวทางการออกแบบระบบกำหนดสิทธิการใช้งานใน AppSheet
การออกแบบระบบสิทธิการใช้งานใน AppSheet โดยส่วนใหญ่แล้ว ทาง Datayolk จะให้องค์กรลองร่างระบบสิทธิการใช้งาน ผ่าน AppSheet Permission Template โดย AppSheet Permission Template จะช่วยให้องค์กรวางแผนการออกแบบระบบสิทธิการใช้งานได้ โดยตารางจะประกอบไปด้วย 3 คอลั่มดังนี้
- สิทธิการใช้งาน (Role) มีสิทธิการใช้งานอะไรบ้างในระบบ เช่น Admin (ผู้ดูแลระบบ), User (ผู้ใช้งานระบบ)
- การเข้าถึง (View) ในสิทธิการใช้งานนี้สามารถเข้าถึง View หรือ หน้าไหนใน AppSheet ได้บ้าง
- การใช้งาน (Action) โดยปกติ Application ทั่วไป จะมีรูปแบบการใช้งานที่เป็นไปได้ทั้งหมด 4 รูปแบบ ได้แก่ สร้างข้อมูล (Create), อ่านข้อมูล (Read), แก้ไขข้อมูล (Update), ลบข้อมูล (Delete)
ซึ่งแต่ละสิทธิการใช้งาน ควรจะใช้งานไม่เหมือนกัน เช่นในหน้ารายการสินค้าจะมีเพียง Admin (ผู้ดูแลระบบ) ที่เข้าไปเพิ่ม (Create) หรือลบ (Delete) รายการสินค้าได้ ส่วน User (ผู้ใช้งานระบบ) สามารถอ่านข้อมูล (Read) รายการสินค้าได้อย่างเดียว (เวลาเขียนใน AppSheet Permission Template เราจะใส่ข้อมูล 4 ตัวนี้เท่านั้นได้แก่ Create, Read, Update, Delete)
ตัวอย่างการใช้ AppSheet Permission Template โดยยกตัวอย่าง Logistic Application
ทางเราจะขอยกตัวอย่างการทำ Application บริหารจัดการทีมขนส่งสินค้า ที่สร้างขึ้นมาเพื่อสื่อสารกับพนักงานขนส่งสินค้า กับพนักงานออฟฟิศ โดยรูปแบบการใช้งานคือ ทีมออฟฟิศจะเป็นคนสร้างคำสั่งซื้อ และรายละเอียดการขนส่ง ส่วนทีมขนส่งสินค้าจะเป็นคนส่งสินค้า และอัปเดตสถานะ รวมทั้งปัญหาอื่น ๆ เช่นการที่สินค้าถูกตีกลับโดยลูกค้า
โดยมี View ต่าง ๆ ดังนี้
- View รายการสินค้าทั้งหมด (ใช้เพื่อดูรายการสินค้าที่มีในระบบทั้งหมด)
- View คำสั่งซื้อ (ใช้เพื่อดูข้อมูลแต่ละคำสั่งซื้อ ซึ่งจะมีข้อมูลย่อย คือ รายการสินค้า และชื่อลูกค้าที่สั่งซื้อ)
- View รายชื่อลูกค้า (ใช้เพื่อดูข้อมูลลูกค้า และที่อยู่ของลูกค้า กรณีที่การขนส่งมีปัญหาจะได้ติดต่อกลับได้)
- View สถานะการขนส่ง (ใช้เพื่อติดตามสถานะการขนส่ง และรายละเอียดการขนส่งแต่ละรอบ)
ถ้ารูปแบบการใช้งานแบบนี้ เราอาจจะสามารถร่างระบบสิทธิการใช้งานได้ออกมาเป็น 3 สิทธิอย่างคร่าว ๆ ดังนี้
| Role | View | Action |
|---|---|---|
| Admin ทีมผู้ดูแลแอปพลิเคชั่น | View รายการสินค้า View คำสั่งซื้อ View รายชื่อลูกค้า View สถานะการขนส่ง | CREATE, READ, UPDATE, DELETE |
| Officer ทีมออฟฟิศดูแล Operation | View คำสั่งซื้อ View สถานะการขนส่ง | CREATE, READ, UPDATE, DELETE |
| Driver ทีมขนส่งสินค้า | View สถานะการขนส่ง | READ, UPDATE |
โดยระหว่างการทำ AppSheet Permission Template ทางเราแนะนำให้เชิญชวนผู้ใช้งานในระบบ AppSheet ทั้งหมดมาร่วมประชุมกันด้วย ซึ่งในที่นี้ได้แก่ ทีมผู้ดูแลระบบ ทีมออฟฟิศ และทีมขนส่งสินค้าเพื่อให้เข้าใจรูปแบบการทำงานจริงมากยิ่งขึ้น
ตัวอย่างเช่นในกรณีด้านบน ทีมขนส่งสินค้า อาจจะต้อง เข้าถึงข้อมูลรายการสินค้า เพื่อสื่อสารกับลูกค้ากรณีสินค้าเสียหายต้องการเปลี่ยนเป็นสินค้าอื่นเป็นต้น สิ่งเหล่านี้ ผู้ออกแบบระบบไม่สามารถคาดเดาได้เองทั้งหมด หากผู้ออกแบบไม่เคยทำงานนั้นเอง
กรณีศึกษาการกำหนดสิทธิการใช้งาน (Permission) ใน AppSheet
จากไอเดียเรื่องการทำระบบกำหนดสิทธิการใช้งานที่กล่าวไปข้างต้น สามารถสรุปออกมาเป็นฟีเจอร์ย่อย ๆ ที่นักพัฒนาสามารถเลือกเอาไปใช้ทำกับระบบของตัวเองได้ดังนี้
ระบบที่ผู้ใช้งานที่เป็น Admin เท่านั้นสามารถกด Approve งานได้
ในกรณี Application บริหารจัดการทีมขนส่งสินค้า เราจะวัดผลการทำงานของทีมขนส่งสินค้าจากสถานะการส่งที่จะต้องมีสถานะเป็น “ขนส่งสำเร็จ” แต่เพื่อคุมคุณภาพงาน เราจะไม่ให้ผู้ใช้งานที่เป็น Driver ปรับเปลี่ยนสถานะเองได้ จนกว่าลูกค้าจะจ่ายเงิน หรือได้รับการอนุมัติจาก Admin เราจึงออกแบบระบบให้ผู้ใช้งานที่เป็น Admin เท่านั้นสามารถเปลี่ยนสถานะการขนส่ง เป็น ขนส่งสำเร็จ ได้
ระบบที่ผู้ใช้งานที่เป็น Driver สามารถเห็นข้อมูลที่ตัวเองบริหารจัดการเท่านั้น
สำหรับ Application บริหารจัดการทีมขนส่งสินค้า เพื่อไม่ให้ทีมขนส่งสินค้าที่มีหลายคนสับสน เราสามารถออกแบบระบบให้ผู้ใช้งานที่เป็น Driver เห็นเฉพาะสถานะการขนส่งที่มีชื่อตัวเองเป็นผู้รับผิดชอบได้ ส่วนผู้ใช้งานที่เป็น Admin จะสามารถเห็นของทุกคนได้ (ในกรณีนี้เราจะใช้ Slicer ในการกรองข้อมูลสถานะการขนส่งสินค้า)
ระบบที่ผู้ใช้งานที่เป็น Admin สามารถเห็นสถานะสินค้าที่เป็น “การขนส่งตีกลับ” แยกออกมา
ในกรณีที่ผู้ใช้งานที่เป็น Driver ไปส่งสินค้าแล้วโดนตีกลับ ผู้ใช้งานที่เป็น Driver สามารถเปลี่ยนสถานะการขนส่งเป็น “การขนส่งตีกลับ” ซึ่งออเดอร์ที่มีสถานะการขนส่งเป็น “การขนส่งตีกลับ” จะแสดงใน View แยกที่มีแต่ผู้ใช้งานที่เป็น Officer และ Admin เห็นข้อมูลทั้งหมดได้เท่านั้น (ในกรณีนี้เราจะใช้ Slicer ในการกรองข้อมูลสถานะการขนส่งสินค้า)
หากยังนึกไม่ออกว่าจะเอาไปใช้ยังไงดี เรามีบทความ 10 ไอเดียลองทำ Application ด้วย AppSheet ให้ไปลองศึกษาดูกัน
ข้อควรระวังอื่น ๆ ในการพัฒนาระบบกำหนดสิทธิการใช้งาน (Permission) ใน AppSheet
นอกจากการออกแบบระบบที่ดีแล้ว เรายังมีข้อควรระวังอื่น ๆ สำหรับนักพัฒนาเพื่อให้สามารถนำระบบกำหนดสิทธิการใช้งานไปในองค์กรได้อย่างมีประสิทธิภาพดังนี้
ยิ่งระบบซับซ้อน Application ยิ่งใช้ยาก
การมีระบบสิทธิการใช้งาน (Role) ทำให้การเพิ่มข้อมูลบางอย่าง อาจจะต้องรอจากคนที่มีสิทธิ Admin ทำให้ นั่นทำให้หากคนที่มีสิทธิ Admin ไม่อยู่ หรือไม่สะดวก จะทำให้งานทั้งระบบช้าไปตาม ๆ กัน หรือหากคนที่มีสิทธิ User เห็นข้อผิดพลาดอะไรบางอย่างก็ไม่สามารถแก้ไขได้เลย ต้องแจ้งกับคนที่มีสิทธิ Admin เพื่อให้เข้าไปแก้ไข เป็นการลดความคล่องตัวในการใช้งานไป (หากนำแอปพลิเคชั่นมาใช้เพื่อความคล่องตัวในการทำงาน สิ่งนี้ควรเป็นสิ่งที่ให้ความสำคัญมาก ๆ)
จากประสบการณ์การให้คำปรึกษาองค์กร ส่วนใหญ่แล้วผู้มีส่วนเกี่ยวข้องในการใช้งาน Application ไม่ควรมีเกิน 3 สิทธิ หากมากกว่านั้นจะทำให้ระบบซับซ้อน ,ใช้งานยาก และมีโอกาสที่จะทำให้แอปพลิเคชั่นช้ามาก ๆ ได้
ส่วนเรื่องแต่ละสิทธิจะทำอะไรได้นั้น ถ้าเป็นไปได้ ทุก ๆ สิทธิ ควรจะอย่างน้อยมีสิทธิการมองเห็นข้อมูลทุกข้อมูลเพื่อให้ช่วยกันสอดส่องข้อผิดพลาดได้ง่าย แต่เรื่องการแก้ไข หรือเพิ่มข้อมูล ก็ให้สงวนสิทธิไว้กับผู้ใช้บางกลุ่มเท่านั้นเหมือนเดิม
ยิ่งระบบซับซ้อน Application ยิ่งช้า
โดยพื้นฐานแล้ว AppSheet ไม่ได้รองรับการทำกำหนดสิทธิการใช้งาน (Permission) ที่ซับซ้อน ตัวอย่างในบทความนี้คือการเขียนโปรแกรมเพิ่มขึ้นมาเอง ซึ่งตอนใช้งานระบบก็จะเตือนว่าสิ่งนี้อาจส่งผลต่อ Performance การใช้งาน หากมีหลายสิทธิการใช้งานมากเกินไป
ทดสอบการใช้งาน ก่อนใช้จริง
เพื่อให้แน่ใจว่า ระบบที่เราคิดมาเหมาะสมกับองค์กรของเรา เราควรมีการทดสอบการใช้งานเบื้องต้นก่อน จะนำไปใช้กับทั้งองค์กร เพราะโดยทั่ว ๆ ไปแล้วระบบกำหนดสิทธิการใช้งาน (Permission) ทำให้ Application ของเราใช้งานยากขึ้น ซึ่งหลังการทดสอบ อาจจะต้องมีการปรับปรุงเพื่อให้ Application ใช้งานไม่ยากจนเกินไป จนไม่มีใครใช้
หลักการพัฒนา Permission สำหรับนักพัฒนา (มีตัวอย่างโค้ด)
สำหรับนักพัฒนา AppSheet หลักการสร้างระบบสิทธิการใช้งาน Permission ใน AppSheet คือการสร้าง Table พิเศษที่บันทึกข้อมูล ผู้ใช้งานในระบบ อีเมล และสิทธิการใช้งาน เช่น
| role | |
|---|---|
| admin@gmail.com | Admin |
| user@gmail.com | Officer |
| driver@gmail.com | Driver |
หลักการคือเวลาจะตรวจสอบเงื่อนไขการใช้งานเราจะเขียนสูตรให้เช็ค อีเมลของผู้ใช้งาน ว่าตรงกับอีเมลไหนในระบบ (Table user) และทำเงื่อนไข ผ่าน สูตร IN() เช่น
IN(USEREMAIL(), SELECT(user[email], ("Admin" = [role]))), TRUE,ในกรณีนี้อ่านว่า ค้นหา Email ในระบบที่ตรงกับ Email ปัจจุบันของผู้ใช้งาน และมี role เป็น admin ที่ table user ถ้าค้นเจอให้ return TRUE ถ้าค้นไม่เจอให้ return FALSE
การ Return TRUE แปลว่าให้แสดงผล View นั้น ส่วนการ Return FALSE แปลว่าไม่ให้แสดงผล View นั้น
จากนั้นเวลาสร้าง View ใด ๆ ใน AppSheet เราจะเขียนเงื่อนไขการแสดงผลในส่วนที่เรียกว่า Show If ที่อยู่ในหน้า UX View ดังนี้
โดยเราสามารถเขียนเงื่อนไขซ้อนกันหลาย ๆ ตัวได้ผ่านการใช้สูตร IFS()
IFS(
IN(USEREMAIL(), SELECT(user[email], ("Admin" = [role]))), TRUE,
IN(USEREMAIL(), SELECT(user[email], ("Officer" = [role]))), TRUE,
IN(USEREMAIL(), SELECT(user[email], ("Driver" = [role]))), FALSE
)ในกรณีนี้อ่านว่า ค้นหา Email ในระบบที่ตรงกับ Email ปัจจุบันของผู้ใช้งาน และมี role เป็น admin ที่ table user ถ้าค้นหาเจอให้ return TRUE ถ้าค้นไม่เจอให้ไปเงื่อนไขต่อไป
เงื่อนไขต่อไปบอกว่า ค้นหา Email ในระบบที่ตรงกับ Email ปัจจุบันของผู้ใช้งาน และมี role เป็น Officer ที่ table user ถ้าค้นหาเจอให้ return TRUE ถ้าค้นไม่เจอให้ไปเงื่อนไขต่อไป
เงื่อนไขต่อไปบอกว่า ค้นหา Email ในระบบที่ตรงกับ Email ปัจจุบันของผู้ใช้งาน และมี role เป็น Driver ที่ table user ถ้าค้นหาเจอให้ return TRUE (แสดงผล View นั้น) ถ้าค้นไม่เจอให้ return FALSE (ไม่แสดงผล View นั้น)
ส่วนการโดยกำหนดสิทธิการใช้งานในแต่ละ Table (ผู้ใช้นี้สามารถอ่าน แก้ไข ลบ หรือสร้างข้อมูลได้มั้ย) เราจะใช้สิ่งที่เรียกว่า Update If ที่อยู่ในหน้า Data View โดยเราจะเขียนเงื่อนไขในลักษณะนี้
IFS(
IN(USEREMAIL(), SELECT(inspector[email], ("admin" = [role]))), "ALL_CHANGES",
IN(USEREMAIL(), SELECT(inspector[email], ("supervisor" = [role]))), "ADDS_ONLY"
IN(USEREMAIL(), SELECT(inspector[email], ("user" = [role]))), "READS_ONLY"
)ในกรณีนี้อ่านว่า ค้นหา Email ในระบบที่ตรงกับ Email ปัจจุบันของผู้ใช้งาน และมี role เป็น admin ที่ table user ถ้าค้นหาเจอให้ return ALL_CHANGES (แปลว่าเพิ่ม ลบ แก้ไข ข้อมูลได้ทั้งหมด) ถ้าค้นไม่เจอให้ไปเงื่อนไขต่อไป
เงื่อนไขต่อไปบอกว่า ค้นหา Email ในระบบที่ตรงกับ Email ปัจจุบันของผู้ใช้งาน และมี role เป็น Officer ที่ table user ถ้าค้นหาเจอให้ return ADDS_ONLY (แปลว่าเพิ่ม และอ่านข้อมูลได้เท่านั้น) ถ้าค้นไม่เจอให้ไปเงื่อนไขต่อไป
เงื่อนไขต่อไปบอกว่า ค้นหา Email ในระบบที่ตรงกับ Email ปัจจุบันของผู้ใช้งาน และมี role เป็น Driver ที่ table user ถ้าค้นหาเจอให้ return READS_ONLY (แปลว่าอ่านข้อมูลได้อย่างเดียว) ถ้าค้นไม่เจอให้ return READS_ONLY (แปลว่าอ่านข้อมูลได้อย่างเดียว)
หมายเหตุ: ในส่วนเงื่อนไขการใช้งานด้านบนทาง AppSheet ให้เลือกใส่ค่าได้ตามค่าด้านล่างนี้
"READ_ONLY",
"UPDATES_ONLY",
"ADDS_ONLY",
"ADDS_AND_UPDATES",
"DELETES_ONLY",
"UPDATES_AND_DELETES",
"ADDS_AND_DELETES",
"ALL_CHANGES"
เมื่อทำเสร็จแล้ว เราสามารถทดสอบรูปแบบการใช้งานผ่านฟีเจอร์ Preview โดยหากเราใส่ อีเมลของผู้ใช้งานที่แตกต่างกันออกไป ระบบจะเข้าไปดูใน Table Permission เพื่อเช็คสิทธิการใช้งาน และแสดงผลแตกต่างกันออกไป
บทส่งท้าย
สุดท้ายนี้ ระบบกำหนดสิทธิการใช้งาน (Permission) ควรเป็นระบบที่ตั้งใจเพิ่มความซับซ้อนในการใช้งาน Application เพื่อป้องกันความผิดพลาดเช่น การปิดสถานะโปรเจค การคำนวนราคาค่าบริการ สิ่งเหล่านี้ ควรจะเพิ่ม ลด แก้ไขข้อมูล โดยคนเฉพาะกลุ่มเท่านั้น หรืออีกกรณีคือเพื่อป้องกันความลับรั่วไหล
แต่การมีระบบที่ซับซ้อนขึ้น นั่นหมายความว่าความง่ายในการใช้งาน หรือ Ease of use อาจจะลดลง ฉะนั้นเวลาจะออกแบบระบบกำหนดสิทธิการใช้งาน (Permission) อาจจะต้องคำนึงถึงส่วนนี้ด้วยว่า
เรากำหนดสิทธิการใช้งาน (Permission) เพื่ออะไร ?
รู้หรือไม่
AppSheet มีกลุ่มผู้พัฒนาคนไทยใน Facebook Group แล้วนะ หากคุณผู้อ่านพัฒนา AppSheet แล้วติดปัญหา สามารถสอบถามในกลุ่ม แชร์ความรู้การใช้งาน AppSheet by Datayolk.net ซึ่งเป็นกลุ่มที่รวบรวมนักพัฒนา AppSheet ในเมืองไทยเพื่อสอบถามปัญหาเกี่ยวกับการใช้งาน AppSheet และแบ่งปันเทคนิคในการสร้างแอปพลิเคชั่น
บทความที่เกี่ยวข้อง
Low-Code ทำให้เราสามารถพัฒนาโปรแกรมได้โดยไม่ต้องเขียนโค้ดเลย แต่ในขณะเดียวกันการไม่เข้าใจเรื่องโค้ดดิ้งก็ทำให้มีความเสี่ยงที่เราจะทำโปรแกรมที่ไม่ปลอดภัยออกมา และทำให้เกิดปัญหาในภายหลัง
บทความนี้ จะรวบรวมเทคนิค และปัญหาการใช้งาน AppSheet ที่มีคนสอบถามจาก Facebook Group เพื่อให้ง่ายต่อการค้นหาวิธีการแก้ไขในภายหลัง
AppSheet ช้าแก้ไขยังไงดี ? ในบทความนี้จะแนะนำวิธีการตั้งค่าใน AppSheet ให้ทำงานได้เร็วขึ้นเรียงตั้งแต่จากง่ายไปยากเพื่อให้ผู้ใช้งานกลับมาใช้ AppSheet ได้ดังเดิม
เพราะการใช้ AppSheet ในการทำงานที่ซับซ้อนมากขึ้นต้องอาศัยการเขียนสูตร ในบทความนี้เลยจะมาแนะนำสูตรที่ใช้บ่อย ๆ สำหรับมือใหม่มาให้อ่านกัน
