简介：《Aras 学习文档》是一份面向 Aras PLM 初学者、系统管理员及实施顾问的 Word 版系统管理使用手册，主要解决用户与权限配置、基础数据建模以及日常系统管理中的入门问题。压缩包内共 1 个 docx 文件，约 11.06MB，以章节目录组织内容，围绕系统管理逐项展开，便于按模块检索和查阅。手册内容覆盖用户管理、登录用户、参与者与特殊参与者，权限创建与发现、可创建者权限、子类对象权限、TOC 访问权限，以及数据类型、列表、外部数据类型、配置序列、对象类型等要点，从账号、角色到权限规则，再到数据类型与对象类型的配置方法均有涉及，能够帮助读者梳理 Aras 的权限模型与数据建模逻辑，也可作为实施过程中的查阅资料。目前已有 1287 人学习，适合需要快速熟悉 Aras PLM 管理界面、理解权限配置思路或补齐系统管理知识的技术人员参考。
1. 先看目录再动手：Aras PLM 后台配置的先后顺序
不少人第一次进入 Aras PLM 后台时，会急着创建用户、创建对象类型，结果对象建出来了，别的账号连左侧导航都看不到；如果在权限模型上犯错，后面每一步都容易白做。这份 Word 版《Aras PLM 系统管理使用手册》正好按配置顺序来写：从用户与参与者、权限、数据类型、对象类型，排到实现类型、关系、生命周期、工作流，再往后是版本集、历史记录、国际化、首选项、包定义、配置管理、操作、文件与窗体。目录本身就是一张后台配置路线图，适合刚接手 Aras PLM 运维与建模的工程师，也适合要给业务方解释“这个字段为什么改不了”的实施人员。后面几章按真实配置顺序展开，每一步都能对照界面复现。
2. 参与者与权限：把「谁能看见什么」设置正确
Aras PLM 的权限不是一张表就能说清的，它是一条链：参与者 → 权限对象 → 访问权（Access）→ 挂到对象类型、属性或关系类型上。链条上任何一环断掉，表现出来的现象都是「看不见」或「点开报错」，但原因完全不同。我见过最多的情况是：权限明明配了，用户登录后还是什么都没有。问题往往出在权限之外：TOC 没配、缓存没清，或者权限挂在了父类型上，用户实际操作的却是子类型。这一章把这条链拆成三段：身份怎么建、权限位怎么勾、导航树怎么挂。
2.1 参与者、登录用户、特殊参与者：三种身份不是同义词
先厘清一个基础概念：Identity 是权限的载体，User 只是「能登录的 Identity」。这句话听起来绕，但它决定了很多现象。比如你给某个人单独发了权限，他离职后换人接手，你得重新配一遍；而如果你给的是 Identity，只改成员关系就行，权限一行都不用动。常见做法是：一个部门或一个角色对应一个 Identity，人放进 Identity 里，权限只发给 Identity，不发给个人 User。这样人员流动时改动面最小，也最不容易漏。
登录用户是已经通过认证、拿到会话的账号，它决定了「你是谁」；参与者决定了「你被当成谁」。这两者在界面上经常对不上：某个账号登录后能看到的菜单很少，多半不是账号有问题，而是它所属的 Identity 没有对应的访问权。
特殊参与者是系统内置的几类身份对象，它们不需要你手动创建，但用起来最容易出问题：
| 特殊参与者 | 覆盖范围 | 常见用途 | 风险点 |
|---|---|---|---|
| World | 所有已登录用户 | 公开只读数据的兜底授权 | 一旦给了写权限，相当于对全员开放 |
| Creator | 当前对象创建者 | 允许创建人修改自己建的数据 | 与「创建后锁定」的流程天然冲突 |
| Owner | 对象当前所有者 | 审批期内临时授权经办人 | 所有者变更后权限跟着漂移，排查时很难找 |
| Administrators | 超级用户组 | 应急排障、结构变更 | 日常业务账号不要往里加，否则越权没有提示 |
创建参与者的步骤不复杂，但命名和层级要先想好。第一步，在后台参与者管理里新建一个 Identity，名称用「部门-角色」这种可读性强的格式，别名（alias）保持全大写英文，后面在方法里取值会用到。第二步，填上级参与者，把组织层级串起来，这样上层授权可以沿层级向下生效。第三步，把 User 加为成员，注意加的是成员关系，不是把 User 设成父级。第四步，回到权限里把该 Identity 加进 Access，这一步才算真正打通。
提示：特殊参与者不要拿来当「省事方案」。World 给的写权限，出问题时几乎无法定位到具体是谁，日志里只有对象变更记录，没有授权链路。
2.2 权限位拆解：can_discover 与 can_add 决定了你看到的界面
一个权限（Permission）对象本身只是个容器，真正起作用的是它下面的访问权（Access）子项：每条 Access 绑定一个 Identity，再带一排权限位。这排勾选项看着差不多，实际语义差别很大，配错的后果也各不相同。
| 权限位 | 实际作用 | 关掉后的典型现象 |
|---|---|---|
| get | 读取对象内容 | 列表能打开，但行是空的或直接提示无权限 |
| update | 修改对象 | 字段变灰，或者保存时弹权限错误 |
| delete | 删除对象 | 删除按钮直接不出现 |
| discover | 能否知道对象「存在」 | 关联搜索里搜不到目标，但知道 ID 又能打开 |
| add | 能否往关系里添加对象 | 关系页签里的添加按钮消失 |
| change access | 能否修改权限本身 | 除管理员外没人能调整授权 |
discover和get的区别是最容易被忽略的一条。它俩的效果很像，但discover管的是「对象在检索、关联选择、下拉里出不出现」，get管的是「拿到 ID 之后能不能读内容」。只给get不给discover，用户会觉得系统「搜不到东西」；只给discover不给get，用户能看到条目，点进去却是空的。这是典型的血泪经验：两个都要给，或者两个都不给。
创建权限的完整流程是四步。第一步，在后台新建 Permission，命名带上对象类型前缀，方便日后反查是谁在用。第二步，在权限下加 Access，选定 Identity，按上表逐位勾选，能少给就少给。第三步，把这个权限挂到挂载点上，对象类型挂类型级默认权限，属性可以单独覆盖，关系类型也有自己的权限。第四步，用一个非管理员账号登录验证，别用管理员账号自测，管理员看什么都是通的，验证不出问题。
注意：
change access一般只留给管理员组。业务 Identity 拿到这个位，等于可以自己给自己扩权，权限模型就形同虚设了。
2.3 TOC 访问权限与子类创建权限：导航树不是默认全开
TOC 就是登录后左侧那棵树。权限系统管的是「能不能访问数据」，TOC 管的是「节点出不出现在导航里」。这是两条独立链路，断哪条表现都不一样，但看起来都像「没权限」。
第一种情况：权限配全了，用户登录后左侧根本没有这个节点。原因是对象类型没有配置 TOC 访问，或者配了 TOC 视图但没挂到对应 Identity 上。第二种情况：TOC 配了，权限没给，节点在那儿，点开是空白或者直接报错。排查时先分清是「看不见入口」还是「进得去但读不到」，前者查 TOC，后者查权限，能省掉一大半时间。
创建子类对象权限是另一处高频误区。权限挂在对象类型上，子类型默认继承父类型的访问权，但「在父类型下创建子类型对象」这件事，往往还需要子类型自身的权限配合。我一般会这样验证：用目标 Identity 登录，从父类型的列表页点新建，看子类型选项在不在；再进子类型的列表页直接新建，看能不能存。两个入口都过了，才算配完整。
还有一种情况是级联失效：改了父类型的权限，子类型上已有的对象突然读不到了。原因是子类型没有自己的独立权限，一直在用父类型的那一份。要避免这种连坐，关键子类型建议单独建权限对象，把访问权显式列出来，别完全依赖继承。
3. 对象类型与数据类型：从 List、Sequence 到属性导入窗体
权限打通之后才轮到建模。这一章是整份手册里篇幅最重的部分，因为它决定了后面关系、生命周期、工作流能不能接得上。建模的顺序错一步，后面就要返工：先定数据类型，再建对象类型，再配属性和版本，最后才把字段挂到窗体上。很多人反过来做，先在窗体上拖控件，回头发现数据类型选错了，改一次牵连一片。
3.1 数据类型选型：List、Sequence 和 Foreign 各自的边界
数据类型是属性的底层定义，选错了不是改个下拉那么简单，已经存进去的数据要跟着迁移。常见的几种类型和适用场景大致如下：
| 数据类型 | 适用场景 | 常见坑 |
|---|---|---|
| String | 短文本、编码、名称 | 长度按最大可能值留余量，后期加长要改结构 |
| Text | 长描述、备注 | 别用来存结构化编码，检索性能差 |
| Integer / Decimal | 数量、金额、工时 | Decimal 要确认小数位数，默认精度常不够 |
| Date | 日期、时间戳 | 注意时区与显示格式是两回事 |
| Boolean | 是否启用、是否冻结 | 别用 String 存 Y/N，后期查询很难写 |
| Item | 引用另一个对象 | 要同时配好被引用类型的 discover 权限 |
| List | 固定枚举值 | 值一多就该考虑换成对象类型 |
| Sequence | 自动编号 | 并发取号不要自己写循环补号 |
| Foreign | 映射外部表或视图 | 多数场景只读，写入要走外部系统 |
列表（List）是最常用的枚举来源。它的结构是两列：Value 存显示值，Filter 存父值，靠 Filter 做级联。比如「产品线-型号」这种两级下拉，就是在同一个 List 里，把型号行的 Filter 列填成对应产品线的值，然后在属性上指定这个 List 作为数据源。级联不生效，九成是 Filter 列填的值和父级 Value 对不上，差一个空格都会失效。
序列（Sequence）负责自动编号。配置项一般包括前缀、当前值、步长和位数，比如前缀PRT-、位数 6，生成出来就是PRT-000123。并发场景下取号是在事务里完成的，不要自己在方法里写「查最大值加一」，两个用户同时提交就会撞号。撞号之后补数据非常麻烦，因为编号往往已经印在图纸或者发到供应商手里了。
外部数据类型（Foreign）用于映射外部系统的表或视图字段。它的特点是「能读不一定能写」，写入通常要走外部系统或者中间方法。我一般的做法是：外部来源的字段一律设为只读，需要回写的场景单独做一个操作按钮走接口，别让用户在属性上直接改，改完了两边不一致，排查成本极高。
3.2 对象类型与类结构：父类、子类和 Polymorphic 的取舍
对象类型（ItemType）是建模的主干。建之前先定三件事：名称、类结构、实现类型。名称就是后面在查询语句里写的type，一旦有数据就基本不能改名，改一次等于把所有引用它的地方全改一遍，所以命名阶段多花十分钟是值得的。
类结构决定这个类型能不能有子类型、父类型的查询能不能把子类型一起捞出来。常见的取舍是：业务概念之间是「是同一类东西但流程不同」，用父类型加子类型；如果是「完全不同的东西」，就各建各的类型，别硬塞进一棵继承树。我见过一个类型下面挂了十几个子类型，属性表长到没人看得懂，最后连窗体都配不动。
继承带来的是属性和默认权限的向下传递，但窗体、TOC 视图、生命周期这些是可以各自覆盖的。也就是说，子类型能继承字段，但不一定继承界面。这点要提前和业务方说清楚，否则会出现「字段明明有，就是在界面上找不到」的争论。
常见做法是先画对象关系图再动手：哪些是主对象，哪些是附属对象，哪些之间是多对多。图画完了，类型数量基本就定了，剩下的都是配置工作。跳过这一步直接开建，大概率会在关系阶段推倒重来。
3.3 属性、版本与窗体：字段真正落到界面上的四步
属性（Property）是对象类型下的字段定义，关键配置项不多，但每一项都影响后面：
| 配置项 | 说明 | 建议 |
|---|---|---|
| name | 查询语句里的属性名 | 用小写英文加下划线，别用中文 |
| label | 界面显示名 | 跟业务术语对齐，别自创缩写 |
| data_type | 数据类型 | 参考上一节的对照表 |
| data_source | 列表或引用类型的来源 | 引用类型要同时确认对方权限 |
| field | 物理列名 | 一般自动生成，别手改 |
| required | 是否必填 | 上线后再加必填会卡住历史数据 |
| unique | 是否唯一 | 唯一约束在建数据之前加，后期加会失败 |
版本这块，版本号通常用字符串类型配序列生成，比如 A、B、C 或者 1、2、3，不要用数字类型：数字类型会把 A 变成 0，把 01 变成 1。版本集的作用是把同一族对象的多个版本聚成一组，方便一次取到全部版本，做对比或者归档时特别有用。配置版本集之前，先把版本属性配好，否则集合里是空的。
窗体是最后一公里。表单（Form）由字段（Field）组成，每个 Field 引用一个属性，可以单独覆盖数据源、宽度和事件。把字段挂上去只是第一步，还要把窗体挂到对象类型的默认窗体和 TOC 视图上，否则用户在界面上永远看不到。标准四步是：建属性 → 建窗体 → 往窗体加 Field 并绑定属性 → 回对象类型指定默认窗体和 TOC 视图。第四步最容易被跳过，跳过了前三步等于白做。
提示：字段在窗体上显示不出来，先查这四步的顺序，再查缓存。顺序对了还看不到，八成是缓存没刷新，换一个没登录过的浏览器验证最快。
4. 关系、实现类型与生命周期：把对象组织成关联结构
单个对象类型能表达的信息有限，真实业务里全是对象之间的关联：零件和图纸、变更单和受影响物料、项目和任务。Aras PLM 用关系类型表达这种关联，用生命周期和工作流表达状态流转。这一章讲的是「结构 + 流程」两层怎么接，接错了会出现数据孤岛或者流程卡死。
4.1 关系类型：相关对象类、关系属性与绑定顺序
关系类型的创建顺序是有讲究的，顺序错了就得重来。正确顺序是：先建好相关对象类（也就是被关联的那个对象类型），再建关系类型并指定源类型和相关对象类，然后回到源对象类型的关系页签把关系挂上，最后配关系的窗体和权限。
关系属性放在关系类型上，不放两端。比如「物料用在某个装配上」这条关系，用量、位号、生效日期这些字段属于关系本身，不属于物料，也不属于装配。放错位置，同一个物料用在不同装配上就没法区分用量了。
关系对象在物理上是一张独立的表，主键由源对象和相关对象共同构成，再加上关系自身的属性列。这意味着同一条关系不能重复创建，重复添加会直接报主键冲突，而不是静默覆盖。遇到「加不进去」的报错，先查是不是关系已经存在。
还有一种结构是独立关系类型：关系对象可以被单独查询，有自己的生命周期和权限。适用场景是关系本身就是一个业务实体，比如「供应商-物料」的供货关系需要走审批。普通的从属关系没必要做成独立的，配置成本高，用户也搞不清该去哪维护。
4.2 关系还是属性：一张判断表
建模阶段最常争论的问题就是这个字段该做成属性还是做成关系。判断标准其实不复杂：
| 场景 | 选型 | 理由 |
|---|---|---|
| 一个对象只对应一个值 | 属性 | 查询简单，窗体直接放字段 |
| 一个对象对应多个同类对象 | 关系 | 属性存不下列表，硬存只能拼字符串 |
| 关联上还要带自己的字段 | 关系 | 关系属性有地方放，属性没有 |
| 关联需要独立权限 | 关系 | 关系类型可以单独配权限 |
| 关联需要走审批 | 独立关系类型 | 关系对象要能挂生命周期 |
| 只是临时标记 | 属性 | 建关系的成本远高于收益 |
一个常见的误用是拿字符串属性存多个 ID，用逗号隔开。这种结构前期省事，后期查询、权限、报表全都要额外写方法去拆，改一次错一次。只要关联数量可能超过一个，就老老实实建关系。
4.3 实现类型与多对象类型：一次查询拿到多种对象
实现类型决定这个对象类型在系统里怎么落地，普通对象、关系对象、多对象类型走的是不同配置。多对象类型指的是一個对象类型下面挂多个子类型，查询时按父类型查能一次拿回全部子类型的结果，按子类型查只返回该子类型。
这个特性很实用，比如「变更对象」下面挂工程变更、文档变更、物料变更，报表要统计所有变更时按父类型查就够了，不用写三个查询再合并。代价是返回结果的字段要对齐：子类型独有的属性在别的子类型记录上是空的，界面上要处理好空值显示。
创建新对象时有个坑：通过多对象类型新建，如果没有显式指定子类型，对象会落到父类型上，之后在任何一个子类型的列表里都找不到它。表现就是「刚建的东西不见了」。解决办法是在新建入口上固定子类型，或者在保存前做校验。
4.4 生命周期与工作流：状态机先定，活动路径后接
生命周期和工作流容易混，其实职责很清楚：
| 维度 | 生命周期 | 工作流 |
|---|---|---|
| 管什么 | 对象处于什么状态 | 谁在什么时间做什么 |
| 核心元素 | 状态、转变 | 活动、路径、分配 |
| 触发方式 | 用户点状态转变 | 流程启动后自动推进 |
| 通知 | 转变上配邮件 | 活动上配通知 |
| 典型用途 | 草稿、评审、发布、作废 | 审批、会签、多级流转 |
顺序上我一般先定生命周期：把状态画出来，标清起始状态和终止状态，再给每条转变配权限，谁能从草稿推到评审、谁能从评审打回。这一步定完，对象的状态语义就清楚了。
工作流是在生命周期之上叠加的。活动是流程节点，路径决定活动之间怎么走，分配决定活动落到哪个 Identity 头上，通知负责发邮件，活动工作列表是待办入口。动态分配需要写方法去计算参与者，配置固定分配搞不定的场景才用它，别一上来就写方法。
状态转变这一环最容易出问题：工作流活动完成后要回写对象状态，如果状态名和生命周期里的定义不一致，流程走完了对象还停在原地。配置完之后一定要走一遍完整流程，别只看流程图对不对。
5. 避坑清单：权限、建模、升级里最容易出错的五处
这一章全部来自实际操作中遇到的问题，按「现象 → 原因 → 解决」写。每一条都能在测试环境复现，建议对照自己的环境过一遍。
5.1 权限相关：看得见和改得动是两码事
现象一：权限全给了，用户登录后左侧导航里没有这个对象类型。原因：TOC 访问没有配置，或者配了 TOC 视图但没挂到目标 Identity 上。权限管数据访问，TOC 管导航显示，两条链路独立。 解决：在对象类型的 TOC 配置里补上视图并指定 Identity，然后让用户重新登录验证。顺手用另一个没登录过的浏览器复核，排除缓存干扰。
现象二：关联搜索里搜不到目标对象，但知道 ID 直接打开又是正常的。原因：只给了get没给discover。检索和下拉走的是发现权限，读取走的是读取权限。 解决：在该对象类型的权限里补上discover位，并把相关 Identity 都加进去。补完之后让用户清一次本地缓存，否则旧权限还在会话里。
5.2 建模与关系相关：改完没生效的几个来源
现象三：属性加上了，窗体也改了，用户界面上就是不显示。原因：窗体没挂到对象类型的默认窗体或 TOC 视图上，或者挂的是另一个视图，用户实际打开的不是那个。 解决：回到对象类型确认默认窗体指向，再确认 TOC 视图用的窗体；两处一致后清缓存重登。这类问题九成出在「配了但没挂」。
现象四：关系类型改完，已有关系的字段全空了。原因：直接改了关系类型的属性定义，或者重新建了关系类型，旧数据挂在原来的结构上。 解决：改结构前先用包定义把关系类型和已有数据导出一份做对照，改完只做增量补录。涉及已有数据的结构变更，一律先在测试环境验证。
5.3 升级与历史记录相关：迁移前没留后路的代价
现象五：导入配置包之后，部分对象类型属性错乱，或者引用断掉。原因：包导入是覆盖式的，标识相同就覆盖，两台环境里同一个名称的对象可能标识不同，导入后就串了。 解决：导入前先导出目标环境的现有定义做差异比对，只导增量；关键对象类型导入后立刻抽查属性和关系的完整性。历史记录如果开了可配置模板，可以在事后追到具体改动，前提是模板里包含了你关心的属性。
6. 上线前的一次回归：用查询语句与配置包核验改动
改完一堆配置，最难的是确认「到底改对了没有」。我的习惯是不靠界面逐项点击，而是走三条核验路径：用查询语句查模型结构，用包定义比对差异，用历史记录做回滚演练。
第一条最好用。在系统的查询入口执行下面这段，能一次把对象类型和它下面的属性都取回来：
<AML> <Item type="ItemType" action="get" select="name,implementation_type"> <name>Part</name> <Relationships> <Item type="Property" action="get" select="name,data_type,data_source,is_required" /> </Relationships> </Item> </AML>type填对象类型的名称，action="get"表示按条件取，select只列需要的字段，减少返回体积；嵌套在Relationships下的属性查询会跟着一起返回，比在界面上一个个点开核对快得多。把name换成你要核验的类型，导出的结果和需求文档里的字段清单逐行对一遍，字段类型、数据源、必填三项对不上就当场改。
第二条是包定义导出。改动前后各导一份，用文本比对工具看差异，重点看对象类型、属性、关系类型、权限这四类。差异里出现你没预期的删除项，基本就是误操作。
第三条是回滚演练。挑一个已发布对象，手动改一次状态再改回来，看历史记录里有没有留下痕迹、可配置模板记录的属性范围对不对。演练不通过就先别上线，真出问题时没有记录可查，只能靠回忆，那才是真正麻烦的。
从那以后我每次改完配置，都会强制走一遍这三条，尤其是第一条查询语句，五秒钟就能看清一个对象类型的全貌。这份 Word 手册可以当作对照表，边看边在环境里核，比通读一遍记得牢。希望帮到你。
本文还有配套的精品资源，点击获取
